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Enel:  (1)  ADS  Management  Methodology  Study 


1.  The  Automated  Data  Systems  (ADS)  Management  Methodology 
Study  was  initiated  to  produce  a set  of  procedures  and 
documentation  to  be  utilized  in  the  Conceptual  Phase  of 
ADS  development. 


2.  The  enclosed  study  has  accomplished  the  stated  objective. 
The  methodologies  proposed  by  the  study  would  be  beneficial 
to  any  ADS  development  effort.  Certain  portions  of  the  study 
such. as  the  Resource  Estimating  Procedure,  will  require 
changes  to  reflect  recent  Department  of  Defense  instructions. 

3.  The  Marine  Corps  intends  to  utilize  the  ADS  Management 
Methodology  Study  as  a base  for  revision  of  current  orders 
pertaining  to  ADS  development.  Appropriate  modifications 
will  be  made  to  Marine  Corps  orders  to  reflect  changes  in 
policies  and  procedures. 

A copy  of  this  letter  will  be  affixed  inside  the  front 
cover  of  each  of  the  subject  study  prior  to  its  distribution. 


L.  F.  SNOWDEN 
Chief  of  Staff 
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PREFACE 

Analysis  by  the  Marine  Corps  has  indicated  that  the  growing  demand 
for  ADS  has  outstripped  the  available  management  capability  to  support 
application  of  the  existing  technology.  For  example,  the  growing  demands 
for  systems  documentation  and  analysis  during  ADS  development  may  be  be- 
yond the  current  capabilities  of  the  Marine  Corps  to  support  satisfactor- 
ily, because  of  the  shortage  of  qualified  personnel  and  inadequate  staffing 
at  the  Headquarters  level.  One  manifestation  of  this  is  that  the  cost 
and  time  necessary  to  develop  and  implement  an  ADS  are  consistently 
underestimated . 

The  problem  is  multifaceted,  and  it  appeared  that  the  most  immediate 
remedy  might  result  from  first  tackling  the  problem  of  ADS  development 
management.  Current  management  is  guided  by  the  Marine  Corps  Automated 
Data  Systems  Manual  (ADSM) . However,  specific  statements  of  duties, 
tasks,  operational  definitions,  and  deliverables  for  individuals  and 
work  teams  are  not  specified  in  the  ADSM  in  sufficient  detail  to  allow 
for  a high  degree  of  efficiency  for  the  average  developer. 

As  a consequence,  HQMC  contracted  with  SRI  International  to  conduct 

a systems  analysis  study  of  the  conventional  management  concepts  expressed 

in  the  ADSM.  The  study  was  to  develop  a methodology,  operational 
* 

definitions,  and  a definitive  statement  of  tasks  and  duties  for  ADS 
development.  Benefits  accruing  to  the  Marine  Corps  from  a successful 
completion  of  the  study  effort  were  to  be  both  economic  and  operational: 

(1)  Economic — if  the  efficiency  of  automated  systems  develop- 
ment is  increased,  there  will  be  a reduction  in  the  time 
and  cost  of  developing  any  given  ADS. 


Operational  Definition:  A specification  of  the  activities  of  a worker 
or  a team  in  developing  and  using  a component  of  an  ADS  development 
plan.  Alternatively,  an  operational  definition  assigns  meaning  to  a 
concept  by  specifying  the  activities  and  operations  necessary  to  pro- 
duce a usable  component  of  an  ADS  development  plan.  Thus,  an  operational 
definition  provides  a bridge  between  theory  and  application. 
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(2)  Operational — if  the  effectiveness  of  automated  systems 

development  is  improved,  the  systems  that  are  developed  in 
x the  future  will  better  conform  to  valid  mission  requirements. 

^ The  specific  objectives  of  the  research  were  as  followsrv 

(1)  ' Operationally  define  the  management  and  analysis  tasks 

and  duties  that  must  be  performed  in  the  preparation 
of  an  ADS  Development  Planj) 

(2)  vOperationally  define  a procedural  methodology  for 

developing  ADS  objectives  and  associated  measures  of 
objective  f alf illmentj 

(3)  -^Develop  specific  methodologies  needed  to  guide  developers 

and  decision  makers  for  ADS  systems  so  that  the  antici- 
pated value  of  the  proposed  system  can  be  assured  and  its 
total  cost  impact  estimated  and  controlled',  ~ 

(4)  ^Assist  HQMC  to  translate  the  study  results  into  procedures 

and  policies. 

\ 

The  study  was  begun  in  mid-1976  and  completed  in  late  1977.  It 
consisted  of  the  following  five  tasks: 

• Task  1:  Objective-Writing  Methodology 

• Task  2:  Resource  Requirements  Estimating  Methodology 

• Task  3:  ADS  Action-Document  Preparation  Procedures 

• Task  4:  ADS  Project  Evaluation  Methodology 

• Task  5:  Integration  and  Refinement  of  ADS  Management 

Methodology. 

SRI  reported  on  the  results  of  Tasks  1,  2,  and  3,  in  individual  Technical 

Notes  issued  during  the  course  of  the  project,  namely,  NWRC-TN-73, 

"Objective-Writing  Methodology  for  USMC  ADS  Development,"  July  1977; 
NWRC-TN-72,  "Resource  Requirements  Estimating  Methodology,"  May  1977; 
NWRC-TN-75,  "Concept  Phase  Procedures  and  Action  Documents,"  September 
1977. 

This,  the  project's  final  report,  has  been  published  in  two  volumes. 
Volume  I addresses  Study  Tasks  1,  2,  and  3,  and  is  designed  for  use  by 
originators/users  in  presenting  the  case  for  a proposed  ADS.  The  material 
originally  contained  in  the  Technical  Notes  has  been  restructured, 
simplified,  and  oriented  as  much  as  possible  to  the  nontechnical  ADS  user. 
Those  desiring  more  detailed  explanations  of  the  results  of  Tasks  1 
through  3 are  encouraged  to  consult  the  Technical  Notes. 
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Volume  II  synthesizes  and  compiles  the  results  obtained  under  Study 
Tasks  1,  2,  and  3 in  order  to  address  the  objectives  of  Tasks  4 and  5. 

It  is  suggested  that  an  originator /user  of  a proposed  ADS  concept  can 
profit  from  reading  both  volumes  of  the  report,  since  the  evaluation 
criteria  presented  in  Volume  II  should,  if  possible,  be  satisfied  by  the 
proposal  documents  treated  in  Volume  I. 

The  study  was  conducted  within  SRI  International's  Naval  Warfare 
Research  Center,  A.  Bien,  Director.  The  Project  Leader  was  David  L. 
Harvey.  Study  team  members  included  Terrance  M.  Keen,  Edward  H.  Means, 
William  Schubert,  and  Graham  F.  Wallace. 
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EXECUTIVE  SUMMARY 


1 


General 


The  ADS  management  methodology  presented  in  this  final  report  is 
designed  to  be  used  in  the  ADS  Concept  Phase  of  development. 

The  final  report  is  divided  into  two  volumes,  one  representing  the 
management  problem  from  the  viewpoint  of  the  proponents  (Volume  I)  and 
the  other  (Volume  II)  from  that  of  the  evaluators  of  a proposed  ADS. 
Volume  I,  therefore,  treats  the  subjects  of  concept  development  and 
action  document  preparation.  Also  included  in  this  volume  are  consider- 
ations of  special  problems,  specifically,  objective  specification  and 
resource  estimating.  Volume  II  specifies  the  procedural  steps  to  be 
taken  in  the  continuing  process  of  project  evaluation  and  executive 
approval/rejection  at  any  of  several  milestones  in  that  process. 

The  Problem 


The  USMC  ADS  development  process  is  guided  generally  by  MCO 
P5200.15  (ADSM)  and  MCO  5230.8  (Maintenance  and  Modification  ... 
Applications  Software  ...)  which  require  further  definition  and 
operational  specificity. 


A number  of  USMC,  U.S.  Navy,  and  DoD  orders,  instructions,  and 
directives  relate  specifically  to  the  ADS  software  development  process.* 
Procedures  and  requirements  dictated  by  those  documents  are  not  clear,  or 
are  not  specified  in  sufficient  detail,  to  allow  for  a high  degree  of 
efficiency  for  the  typical  Marine  officer  who  is  often  assigned  the  ADS 


*SECNAVINST  5233. 1A,  DODINST  4120.7,  DODINST  4120.17,  SECNAVlaST  7000. 14B, 
SECNAVINST  5231.1,  DODINST  5010.27  (79XX.SS),  DODINST  7041.3. 


S-l 


development  or  evaluation  tasks  as  adjuncts  to  his  regular  duties. 
Specific  problem  areas  for  which  this  study  is  designed  either  to  allevi- 
ate or  assist  USMC  users  to  function  within  the  constraints  imposed  are: 


« Clearly  stated  requirements  and  procedures  for  preparing  the 
specified  action  documents 

• Clearly  defined  review  and  approval  procedures 

• Additionally,  the  methodology  should  facilitate  specific  USMC 
staffing  concerns  of: 

- Personnel  shortage  leading  to  inadequate  staffing 

- Insufficient  interest  and  support  b>  involved  parties 

- Division  of  responsibility  between  USMC  divisions 

- Personnel  turnover  during  development  process. 

Assumptions /Limitations 


This  methodology  is  limited  to  the  management  of  new  ADS  and  majir 
ADS  modifications  and  maintenance  projects  that  are  covered  under  the 
ADSM  directives. 


The  applicability  of  this  methodology  is  described  in  Section  1.2. 

The  ADSM  procedures  apply  to:  all  new  and  replacements  to  existing  ADS, 
all  tactical  ADS,  all  purchased  software  costing  more  than  $15,000,  all 
maintenance/modifications  of  existing  ADS  requiring  more  than  three  man- 
months  of  analysis  and  programming  effort,  and  any  ADP  resource  expendi- 
ture exceeding  $100,000.  This  methodology  likewise  applies  in  the 
aforementioned  circumstances  except  that  the  research  has  been  specifically 
limited  to  non- tactical  ADS,  and  non- imbedded  computer.  Recommendations 
for  changing  those  criteria  are  also  discussed  in  Section  1.2  and  listed 
in  this  summary  under  "Recommendations." 

Generally,  the  procedures  specified  here  and  in  the  ADSM  require  a 
minimum  (but  not  trivial)  effort  in  preparing  an  /JDS  development  plan. 

That  means  that  the  assigned  staff  must  have  some  familiarity  with  ADS 
development  procedures  and  terminology,  and  with  alternative  approaches. 

The  proposed  format  for  the  action  documents  is  specified  in  explicit 
detail  with  lead-'n  sentences,  and  fill-in  blanks  with  instructions  as 
to  what  is  to  be  filled  in.  This  format  is  considered  to  be  extremely 
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important  in  order  to  standardize  the  method  by  which  ADS  plans  are 
developed  and  evaluated.  The  imposed  structure  may  appear  awkward, 
excessive,  and/or  redundant  in  a number  of  applications,  and  at  times  it 
may  appear  too  brief.  This  limitation  should  be  viewed  as  a necessary 
expense  to  ensure  adequate  management  control  across  a wide  application 
of  a standardized  methodology.  It  is  possible,  of  course,  to  respond 
in  the  prescribed  format  with  the  comment,  "not-applicable,"  or  in  short 
paragraphs  when  the  information  demanded  is  either  inappropriate  or 
obvious. 

Results 


ADS  development  management  control  is  achieved  through  the  pre- 
scribed research,  preparation,  and  approval/rejection  action  taken  in 
prosecuting  the  following  documents: 

• Requirements  Statement  (RS) 

• Feasibility  Study  (FS) 

• ADS  Development  Plan  (ADSDP) , consisting  of: 

- Body  of  plan  plus  appendices: 

(a)  Functional  Description  (FD) 

(b)  Data  Requirements  Document  (RD) 

(c)  ADP  Equipment  Specifications  (ADPES) 

(d)  Economic  Analysis  (EA) . 


Sample  forms  and  specific  instructions  for  each  of  the  preceeding 
documents  are  contained  in  Section  4. 


Two  specific  problems  in  this  process  that  were  considered  from 
the  onset  of  this  study  to  be  of  sufficient  importance  to  warrant 
separate  reports: 

• Defining  explicit  objectives  for  an  ADS  being  developed  to 
meet  perceived  information  processing  requirements. 

• Resource  estimating  methodology. 


To  assist  the  Marine  officer  in  preparing  portions  of  the  Feasibility 
Study  and  ADS  Development  Plan,  Section  5 presents  a technique  termed 
"Objective-Writing,"  to  be  used  for  defining  the  objectives  of  an  ADS 
being  developed  to  meet  a user's  perceived  information  processing  re- 
quirements. Whether  or  not  the  use  of  this  technique  is  warranted  is  a 
matter  of  individual  judgment.  Its  specific  purpose  is  to  provide  a 
systematic  approach  to  producing  a body  of  objective  statements  that 
avoids  the  possibility  that 

• Objectives  might  not  be  explicitly  stated 

• Objectives  might  not  fully  cover  user  requirements 

s Objectives  might  be  contradictory 

• The  fulfillment  of  objectives  might  not  be  measurable. 

If  risk  of  those  hazards  is  low,  then  full  use  of  the  five  objective 
writing  techniques  is  certainly  unnecessary.  However,  even  the  most 
straightforward  proposal  would  likely  benefit  by  the  use  of  one  or  more 
of  the  techniques  offered. 

ADS  resource  estimating  is  another  area  in  which  there  are  no 
generally  accepted  standards  or  procedures.  The  recommended  procedure 
presented  in  Section  6 is  based  on  taking  the  best  features  of  the  U.S. 
Army's  Fort  Lee  method  and  the  USMC  Kansas  City  resource  estimating  pro- 
cedure, current  micro-  and  macroestimating  techniques  for  use  in  the 
concept  phase  for  estimating  both  development,  and  operations  and  support 
costs.  The  use  of  those  techniques  is  not  a requirement  for  either  the 
feasibility  study  or  economic  analysis;  however,  through  the  repeated 
use  of  this  estimating  approach,  resource  estimates  will,  in  time, 
become  more  accurate  and  reliable. 


Actual  management  control  in  the  concept  formulation  phase  is 
exercised  through  the  approval/rejection  action  taken  at  each 
succeeding  step  from  the  statement  of  user  requirements,  (RS),  to  the 
Milestone  4 decision,  (approval/rejection  of  the  ADSDP) . 


The  measure  of  a good  methodology  is  its  ability  to  terminate  un- 
economic proposals  while  expediting  those  that  are  needed  and  warranted. 
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That  is  the  quality  sought  in  the  recommended  "Project  Evaluation 
Methodology"  (Volume  II  of  this  report).  The  first  issue  concerns  need 
and  feasibility,  basically , the  question,  "Should  it  be  done?"  The 
second  issue,  provided  it  is  approved  to  this  point,  concerns  the  es- 
tablishment of  priorities  for  the  new  project  with  respect  to  the  other, 
ongoing,  ADS  projects  drawing  on  USMC  programmer-analyst  resources. 

Recommendations 


(1)  The  methodology  set  forth  in  these  two  volumes  should  be  incorpo- 
rated into  a revised  ADSM. 

(2)  All  future  ADS  proposals  should  be  processed  in  accordance  with 
the  revised  ADSM,  with  the  thresholds  based  on  the  suggested 
criteria  presented  in  Section  4,  Volume  II,  of  this  study. 

(3)  Until  the  ADSM  is  revised,  the  ADSM/ 5230. 8 thresholds  as 
summarized  in  Section  1 should  be  applied  in  determining 
whether  ADSM  procedures,  as  modified  by  this  study,  or  5230.8 
procedures  are  appropriate  for  a proposed  ADS. 


The  Concept  Phase  is  characterized  by  a series  of  subphases  and 
events  listed  in  Section  3.  Implicit  in  them  are  four  decision  points 
where  resources  must  be  conmltted  before  further  concept  development 
can  continue.  Three  of  the  decision  points  can  be  linked  to  a corre- 
sponding action  document  as  follows: 

• Section  3.1  - Requirements  Development  Subphase;  identify  and 

document  user  requirements. 

Action  document  - Requirements  Statement  (RS). 

• Section  3.2  - Feasibility  Study  - develop  and  evaluate 

alternative  approaches  and  select  preferred 

approach. 

Action  document  - Feasibility  Study  (FS) . 

• Section  3.3  - Prepare  the  ADS  Development  Plan. 

Action  document  - Subsidiary  action  documents 

for  the  ADSDP. 

Approval  of  the  action  document  should  be  t nllcit  approval  for 
resources  needed  to  complete  the  next  activity/event.  A procedure  for 
authorizing  the  connitment  of  resources  is  discussed  in  Volume  II.  The 
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fourth  decision  point  (Milestone  U of  the  ADSM)  is  the  approval  or 
rejection  of  the  ADSDP,  which,  if  approved,  authorizes  resources  needed 
to  proceed  with  the  Analysis  and  Design  (Milestone  5)  of  the  proposed 
ADS. 


SECTION  1 . INTRODUCTION 


1.1  General.  As  pointed  out  in  the  Preface,  this  volume  is  a compilation 
of  a series  of  Technical  Notes  prepared  during  the  conduct  of  the  study. 
Those  documents  presenting  interim  results  were  published  as  specific 
tasks  of  the  study  and  were  completed  in  accordance  with  a stipulated 
schedule.  The  Technical  Notes  have  provided  the  basis  for  the  individual 
sections  of  this  report,  described  below. 

Sections  2,  3,  and  4 discuss  the  overall  ADS  development  process, 
the  Concept  Phase  in  particular,  and  the  action  documents  required  in 
the  Concept  Phase.  As  guided  by  the  Study  Directive,  the  sections  opera- 
tionally define  and  document  the  management  and  analysis  tasks  that  are 
essential  in  the  preparation  of  the  action  documents.  The  procedures 
specified  in  the  sections  satisfy  all  applicable  external  and  internal 
directives.  They  are  as  simple  as  possible,  given  the  complexity  of  the 
subject  matter,  and  they  are  not  form-bound.  They  are  designed  for  easy 
incorporation  into  a revised  USMC  ADS  Manual,  if  that  is  desired.  Some 
of  the  action  document  preparation  procedures  require  reference  to 
Department  of  Defense  Manual  (DODM)  4120. 17-M,  "Automated  Data  System 
Documentation  Standards  Manual,"  December  1972,  and  Department  of 
Defense  Instruction  (DODI)  7041.3,  "Economic  Analysis  and  Program  Evalu- 
ation for  Resource  Management,"  18  October  1972.  This  reference  material 
should  be  at  hand  for  users  of  this  document. 

Having  been  presented  the  overall  picture  of  ADS  development,  the 
reader/user  of  this  document  is  given  his  first  step  in  ADS  implementa- 
tion. This  is  done  in  Section  5,  "Objective-Writing  Methodology  for 
USMC  ADS  Development."  The  section  addresses  two  overall  concerns: 

(1)  how  to  develop  and  express  objectives  for  an  ADS  being  newly  devel- 
oped or  modified  (objective-writing),  and  (2)  how  such  ADS  objectives 
properly  enter  into  the  process  of  USMC  systems  development. 

Section  6,  "Resource  Requirements  Estimating  Methodology,"  discusses 
the  requirement  for,  and  means  of,  achieving  accurate  and  reliable  esti- 
mates of  ADS  life  cycle  resources  (manpower  and  dollar  outlays)  needed 
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to  develop  and  operate  ADS  systems.  Life  Cycle  Cost  (LCC)  estimates 
are  particularly  critical  in  the  early  system  development  or  initiation 
stages  because  it  is  during  this  phase  that  management  has  the  greatest 
opportunity  to  select  and  optimize  satisfaction  of  a requirement  among 
alternative  solutions.  For  this  reason,  first-cut  LCC  estimates  are 
specified  as  early  as  the  feasibility  study  stage. 

There  are  numerous  DoD,  SECNAV,  and  USMC  directives  specifying  a 
requirement  for  Life  Cycle  Cost  estimates.  However,  there  appears  little 
consensus  among  either  industry  or  DoD  agencies  as  to  how  those  estimates 
are  to  be  provided.  Section  6 presents  two  estimating  techniques  (macro 
and  micro),  which,  although  not  mutually  exclusive,  tend  to  be  applied 
at  different  times  in  the  development  of  the  ADS  concept  into  an  ADSDP 
(Automated  Data  System  Development  Plan).  The  approaches  parallel,  and, 
we  hope,  contribute  to,  efforts  within  DoD  agencies  and  within  industry 
in  the  continuing  attempt  to  develop  resource  estimating  standards. 

1.2  Applicability  of  the  ADS  Management  Methodology.  The  recommended 
ADS  mangement  methodology  set  forth  in  these  two  volumes  is  a detailed, 
thorough  process  designed  to  prevent  costly  mistakes  in  the  introduction 
of  new  or  modified  USMC  ADS.  Accordingly,  the  methodology  is  not  fully 
applicable  to  all  ADS  proposals,  particularly  those  that  are  so  small 
(in  their  development  cost  or  potential  benefits)  that  application  of 
the  full  process  described  herein  would  not  be  economically  warranted. 

This  consideration  requires  that  there  be  established  some  definite 
criteria  whereby  the  sponsor  of  a proposed  ADS  may  determine  the  review 
and  approval  methodology  that  is  applicable  to  his  proposal  at  the  out- 
set. Under  the  current  directives,  the  ADSM  and  MCO  5230.8,  the  cri- 
teria are  difficult  to  understand,  and  their  clarification  is  sorely 
needed . 

As  we  read  them,  the  existing  directives  set  the  following  appli- 
cability rules: 

a.  The  ADSM  procedures  apply  to: 


(1)  All  new  ADS. 

(2)  All  replacements  of  existing  ADS. 

(3)  All  tactical  ADS. 

(4)  Commercially  acquired  software  costing  more  than 
$15,000. 

(5)  Maintenance  or  modification  ADS  projects  (except 
changes  directed  by  higher  authority)  requiring 
more  than  three  man-months  of  analysis  and  program- 
ming effort. 

(6)  Any  ADP  resource  expenditure  exceeding  $100,000. 

b.  MCO  5230.8  procedures  presumably  apply  to  all  other  ADS 
proposals,  particularly  maintenance  and/or  modifications 
of  existing  ADS,  however. 

c.  Apparently  not  covered  by  either  the  ADSM  or  MCO  5230.8  are: 

(1)  Maintenance  efforts  required  to  correct  abnormal 
endings  (abends)  which  are  considered  to  be  "self- 
justifying." 

(2)  Systems  designed  purely  to  support  research  and 
development  projects  that  do  not : 

(a)  Involve  acquisition  of  ADPE  with  RDT&E  funds 

(b)  Include  an  ADS  as  an  end  item  or  product  of 
the  project. 

Additionally,  neither  document  offers  guidelines  for  determining 
how  much  effort  should  be  expended  on  proposal  preparation  and  review. 
This  issue  as  well  as  item  (3)  above  is  discussed  in  Section  4 
Volume  II,  of  this  report. 
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SECTION  2.  ADS  DEVELOPMENT 


2.1  Context.  The  USMC  ADS  development  process  is  organized  into  three 
consecutive  major  phases:  the  Concept  Phase,  the  Development  Phase,  and 
the  Operation  Phase.  Within  each  major  phase  are  several  subphases, 
which  are  not  always  consecutive,  but  are  sometimes  parallel  or  overlap- 
ping. These  phases  and  subphases  are  illustrated  in  Figure  2-01. 

The  methodology  developed  in  this  study  is  designed  to  be  applied 
in  the  Concept  Phase.  Major  improvements  have  been  made  in  the  defini- 
tion of  the  Concept  Phase.  One  of  them  comes  from  the  recognition  that 
the  Concept  Statement — heretofore  specified  under  ADSM  procedures  as  the 
initial  action  document  in  any  ADS  development — did  not  provide  an  ade- 
quate vehicle  for  defining  the  prospective  user's  information  processing 
requirements.  Thus,  the  Concept  Statement  had  a tendency  to  focus  atten- 
tion on  an  information  system  solution  without  an  adequate  statement  of 
the  problem  to  be  solved.  This  inadequacy  has  been  addressed  by  specify- 
ing a Requirements  Statement  as  the  document  needed  to  initiate  an  ADS 
development.  This  provision  for  the  explicit  statement,  validation, 
and  approval  of  the  user's  requirements  as  the  logical  starting  point  for 
an  ADS  development  is  a significant  improvement  in  the  development  pro- 
cess. Another  improvement  results  from  the  separation  of  unlike  concerns. 
This  is  achieved  at  several  points  in  the  process.  An  example  is  the 
disentangling  of  feasibility  considerations  from  those  of  user  need.  The 
prospective  user  should  be  free  to  articulate  his  need  or  requirement 
without  being  diverted  by  questions  of  feasibility,  which  should  be 
investigated  independently.  This  situation  is  formalized  by  the  provi- 
sion of  separate  requirements  development  and  feasibility  study  subphases. 
This  illustrates  an  underlying  philosophy  of  the  ADS  development  instruc- 
tions, namely,  that  activities  or  responsibilities  should  not  be  levied 
on  persons  or  groups,  who,  by  their  nature,  are  not  well-suited  to  them. 
This  philosophy  has  two  major  implications.  One  is  that  the  prospective 
user  (i.e.,  the  person  or  group  that  recognizes  an  apparent  information 
system  need  and  that  initiates  an  ADS  development)  is  left  as  free  as 
possible  of  requirements  that  presuppose  ADP  knowledge  on  his  part  or 
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that  require  him  to  be  cognizant  of  management  or  resource  considerations 
normally  outside  his  purview.  The  instructions  laid  on  the  user  are 
equally  applicable  whether  the  users  be  staff  officers  in  an  FMF  command, 
supply  officers  at  a SASSY  Management  Unit,  functional  area  specialists 
at  HQMC,  or  ADP  specialists  at  a Field  Automated  Services  Center.  The 
second  implication  is  that  an  ADS  Development  Team  will  not  necessarily 
have  a fixed  composition  throughout  the  successive  phases  of  development. 
Although  the  Team  must  have  continuity,  the  types  of  competence  required 
to  carry  out  one  phase  of  development  will  be  different  from  those 
required  for  carrying  out  another.  Hence,  different  people  will  serve 
on  the  Development  Team  at  different  times. 

Because  th^  Concept  Phase  involves  planning  for  the  other  phases, 
those  phases  were  also  analyzed.  Some  problems  that  have  affected  all 
phases  of  ADS  development  are  discussed  in  the  next  paragraph.  Begin- 
ning with  Section  3,  the  discussion  is  limited  to  the  nature  and  process 
of  the  Concept  Phase. 

2.2  General  Problem  Areas.  Listed  below  are  four  broad  problems  that 
have  occurred  in  ADS  development.  The  first  three  should  be  alleviated 
by  the  ADS  Management  Methodology  developed  in  this  study,  as  indicated 
in  the  individual  discussions.  The  fourth  is  institutional,  and  hence 
is  not  amenable  to  alleviation  by  the  ADS  Management  Methodology. 

2.2,1  Personnel  Shortage/Inadequate  Staffing.  This  problem  involves  a 
shortage  of  qualified  personnel  and  inadequate  staffing  at  the  Head- 
quarters level. 

It  is  highly  probable  that  the  problem  results  from  insufficient 
knowledge  of  what  numbers  and  types  of  personnel  are  required  in  an  ADS 
development.  The  methodology  developed  in  this  study  should  help  alle- 
viate the  problem  by  requiring  that  personnel  resource  requirements  be 
explicitly  estimated  at  the  earliest  possible  times.  A basis  for  such 
estimates  is  given  in  SRI/NWRC-TN-72,  "Automated  Data  Systems  (ADS) 
Management  Methodology,  Task  2 Report:  Resource  Requirements  Estimating 
Methodology,"  May  1977. 
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2.2.2  Insufficient  Interest  and  Support.  This  problem  involves  insuf- 
ficient interest  in  and  support  of  ADS  development  by  the  users/sponsor. 

It  is  likely  that  this  problem  results  in  part  from  insufficient 
involvement  of  the  users  or  the  sponsor  in  requirements  development,  and 
in  part  from  the  enormous  amount  of  repetitive,  boring,  and  meaningless 
paperwork,  based  on  nebulous  guidance,  that  has  been  required  in  connec- 
tion with  ADS  development.  The  methodology  developed  in  this  study 
should  help  to  alleviate  the  problem  by  assuring  that  user  requirements 
are  clearly  and  completely  stated  and  validated,  by  streamlining  the 
paperwork  insofar  as  permitted  within  the  constraints  imposed  by  external 
directives,  and  by  providing  instructions  that  are  as  concrete  as  pos- 
sible. 

Another  possible  cause  of  this  problem  is  that  the  overall  workload 
of  the  users  or  the  sponsor  may  be  excessive,  and  that  other  projects 
may  carry  a higher  priority  than  the  ADS.  The  solution  in  this  case, 
naturally,  would  be  to  reduce  the  workload  or  rearrange  priorities. 

2.2.3  Division  of  Responsibility.  This  problem  involves  division  of 
responsibility  between  various  stages  of  the  ADS  development  process. 

One  method  of  alleviating  it  is  to  specify  identifiable  milestones  that 
must  be  attained  before  responsibility  can  be  transferred.  This  will 
help  prevent  situations  such  as,  for  example,  a processing  center's 
being  held  responsible  for  the  output  quality  of  an  ADS  that  has  not 
been  fully  tested  and  debugged.  Another  alleviation  method  is  to 
establish  definite  interfaces  between  areas  of  responsibility.  These 
milestones  and  interface  definitions  are  provided  for  in  the  methodology 
developed  in  this  study,  particularly  in  the  ADS  Development  Plan. 

2.2.4  Personnel  Turnover.  This  problem  involves  turnover  of  key  per- 
sonnel during  the  ADS  development  period.  The  term  "key  personnel"  is 
assumed  to  include  managers  and  senior  technical  personnel. 

One  approach  might  be  not  to  assign  a Marine  to  an  ADS  development 
unless  he  has  sufficient  remaining  time  in  his  present  tour  of  duty  to 
follow  the  project  through.  There  are  some  problems  with  this,  however. 
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For  one  thing,  a Marine  might  not  have  attained  enough  knowledge  to  be 
assigned  a key  job  until  he  has  been  in  his  job  a significant  amount  of 
time.  In  such  a case  he  would  have  correspondingly  less  time  remaining. 
Also,  some  ADS  development  may  be  planned  to  extend  beyond  normal  tours 
of  duty.  If  a Marine's  tour  in  a specialized  job  such  as  ADS  development 
were  extended,  it  would  very  likely  be  detrimental  to  his  career. 

Another  approach  might  be  to  assign  only  Civil  Service  personnel 
to  key  positions.  An  obvious  drawback  to  this  is  that  Marines  should 
constitute  the  top  management  of  the  Marine  Corps.  Officers  can  be 
prepared  for  top  management  only  by  becoming  knowledgeable  and  experienced 
in  all  aspects  of  Marine  Corps  operations,  including  data  systems.  There- 
fore, some  of  the  key  personnel  in  ADS  developments  must  be  Marines. 

A compromise  approach  would  be  to  assign  Marines  to  the  more  func- 
tionally oriented,  but  still  crucial,  systems  development  positions. 

Civil  Service  personnel  could  be  assigned  to  the  more  technically  oriented 
ones,  with  a Marine  in  overall  command.  To  be  effective,  this  approach 
would  require  that  a sufficient  overlap  period  be  provided  for  in  move- 
ments of  Marines  into  and  out  of  key  positions.  This  approach  is  some- 
what inefficient  when  viewed  solely  in  terms  of  ADS  development,  but 
taking  such  a view  is  suboptimizing.  The  objective  is  to  optimize  the 
operation  of  Marine  Corps  as  a whole;  this  makes  inefficiencies  in  some 
technical  operations  inevitable. 
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SECTION  3.  THE  CONCEPT  PHASE  OF  ADS  DEVELOPMENT 

The  Concept  Phase  of  ADS  development  begins  with  the  identification 
of  an  apparent  information  system  requirement  and  ends  with  a decision 
on  whether  to  develop  a system  to  satisfy  the  requirement. 

The  Concept  Phase  is  subdivided  into  three  subphases:  Requirements 
Development,  Feasibility  Study,  and  ADS  Development  Planning.  Each  sub- 
phase culminates  in  the  submission  of  a self-contained  "action  document" 
for  approval  by  the  appropriate  authority.  The  activities  and  action 
documents  involved  in  each  subphase  are  described  in  the  paragraphs  that 
follow. 

3.1  Requirements  Development  Subphase.  This  subphase  is  initiated 
informally  by  interested  functional  managers  and  users.  The  initiators 
should  identify  all  potential  users  and  invite  them  to  participate  in  the 
subphase.  Interested  organizations  will  assign  participants  as  required. 
The  activities  in  the  subphase  are  listed  below;  detailed  instructions 
for  each  activity  are  given  as  part  of  the  Requirements  Statement  (RS) 
preparation  instructions  in  paragraph  4.2  of  Section  4,  following. 

a.  Identify  and  document  all  user  requirements 

b.  Validate  the  user  requirements 

c.  Suggest  some  conceptual  approaches  to  satisfying  the  user 
requirements 

d.  Estimate  the  resources  required  for  developing  the  concepts, 
selecting  the  preferred  approach(es) , and  preparing  an  FS 
and  an  ADSDP 

e.  Compile  the  information  in  (a)  through  (d'  into  a Require- 
ments Statement  (RS) . 


3.2  Feasibility  Study  Subphase.  This  subphase  is  initiated  by  approval 
of  the  RS,  which  implies  the  commitment  of  the  resources  required  to 
develop  alternative  approaches  to  satisfying  the  user  requirements.  As 
part  of  the  subphase  initiation  directive,  a System  Sponsor  is  appointed. 
A Feasibility  Study  (FS)  Team  is  also  appointed  for  the  subphase.  The 
team  should  include  members  with  broad  experience  in  various  functional 


II 


Cl 


WECEDINO  PAGE  BUltC-NOT  FILMED 


* 


areas  of  the  Marine  Corps  so  that  the  USMC-wide  impacts  of  proposed 
alternative  approaches  can  be  identified  and  analyzed  in  the  FS.  The 
activities  in  the  subphase  are  listed  below;  detailed  instructions  for 
each  activity  are  given  as  part  of  the  FS  preparation  instructions  in 
paragraph  4.3  of  Section  4. 

a.  Formulate  objectives  for  and  develop  alternative  approaches 
to  satisfying  the  user  requirements. 

b.  Determine  whether  the  alternative  approaches  are  technically 
and  operationally  feasible. 

c.  Estimate  the  costs  of  the  feasible  alternative  approaches. 

d.  Identify  and  evaluate  any  beneficial  effects  (beyond  the 
satisfaction  of  user  requirements)  that  the  feasible  alter- 
native approaches  would  have  on  the  mission  effectiveness 
of  the  Marine  Corps  or  any  of  its  subdivisions. 

e.  Select  the  preferred  approach (es) , 

f.  Compile  the  information  in  (a)  through  (e)  into  a Feasibility 
Study  (FS)  according  to  the  instructions  in  paragraph  4.3. 

g.  If  necessary,  revise  the  estimate  of  the  resources  required 
to  prepare  an  ADSDP. 

h.  Submit  the  FS  and  the  revised  estimate  for  approval.  It 
is  the  responsibility  of  C4  (Headquarters)  to  determine  the 
appropriate  approval  authority.  The  approval  process  is 
the  standard  military  staffing  process. 

3.3  ADS  Development  Planning  Subphase.  This  subphase  is  initiated  by 
approval  of  the  FS,  which  implies  the  commitment  of  the  resources 
required  for  preparing  an  ADSDP.  As  part  of  the  subphase  initiation 
directive,  an  ADSDP  Team  is  appointed  for  the  subphase.  The  activities 
are  given  as  part  of  the  action  document  preparation  instructions  in 
paragraphs  4.4  and  4.5  of  Section  4. 

a.  Perform  the  analyses  necessary  for  compiling  the  subsidiary 
action  documents  (see  paragraph  4.4)  that  must  be  appended 
to  the  ADSDP.  These  analyses  must  include  cost-performance 
tradeoffs. 

b.  Compile  the  subsidiary  action  documents. 

c.  Prepare  the  ADSDP. 

d.  Submit  the  ADSDP  for  approval. 
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4.1  General  Instructions.  This  section  presents  information  for  pre- 
paring each  action  document  required  in  the  Concept  Phase,  including  the 
subsidiary  action  documents  referred  to  in  paragraph  3.3a  of  the  pre- 
ceding section. 

Instructions  for  the  individual  documents  are  presented  in  the  form 
of  action  document  outlines.  The  outlines  themselves  contain  unbracketed 
and  bracketed  material.  The  unbracketed  material  must  be  included  ver- 
batim; it  establishes  the  document  frameworks  and  provides  the  basis  for 
mutual  understanding  of  document  contents  by  both  the  preparers  and  the 
intended  audience. 

The  bracketed  material  comprises  instructions  to,  and  guidelines 
for,  the  document  preparers.  The  instructions  are  of  two  general  types: 
administrative  and  substantive.  The  administrative  instructions  deal 
with  dates,  references,  organizational  matters,  and  other  administrative 
details;  they  are  quite  specific.  The  substantive  instructions,  on  the 
other  hand,  deal  with  the  particular  information  problem  being  addressed 
and  the  suggested  solution  approaches,  and  depend  upon  an  understanding 
of  ADS  technology  and  the  problem. 

The  substantive  instructions,  by  their  nature,  cannot  be  made  very 
specific.  Thus,  preparation  of  the  action  documents  cannot  be  treated 
as  a mechanical  process.  The  process  requires  intelligence,  creativity, 
and  concentration.  No  set  of  instructions  can  provide  the  substantive 
knowledge  and  information  that  are  required  for  high-quality  action 
documents — only  qualified  people  can  do  that. 

4.2  Requirements  Statement  (RS).  Figure  4-01*  presents  the  outline  of 
the  RS,  which  is  to  be  prepared  in  accordance  with  the  general  instruc- 
tions in  paragraph  4.1. 

The  completed  RS  is  to  be  submitted  under  a cover  letter  to  the 
appropriate  approval  authority  identified  by  C4. 


*A11  figures  are  presented  immediately  following  the  text  of  this  section. 
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4.3  Feasibility  Study  (FS).  Figure  4-02  presents  the  outline  of  the 
FS,  which  is  to  be  prepared  in  accordance  with  the  general  instructions 
in  paragraph  4.1. 

The  FS  is  to  be  submitted  under  cover  letter  to  the  appropriate 
approval  authority  identified  by  C4 . The  cover  letter  shall  contain  any 
revisions  that  may  be  required  to  Section  7 of  the  RS;  if  none  is  re- 
quired, the  cover  letter  shall  so  state.  To  provide  the  decision  maker 
with  complete  historical  background,  the  RS,  the  cover  letter  under 
which  it  was  submitted,  and  the  RS  approval  document  shall  be  appended 
to  the  submission. 

4.4  Subsidiary  Action  Documents  for  the  ADS  Development  Plan  (ADSDP). 


As  indicated  in  paragraph  3.3  of  Section  3,  the  ADSDP  is  the  action  docu- 
ment that  culminates  the  ADS  Development  Planning  Subphase  of  the  Concept 
Phase.  Four  subsidiary  action  documents  must  be  prepared  in  connection 
with  the  ADSDP:  the  Functional  Description  (FD) , the  Data  Requirements 
Document  (RD) , the  ADP  Equipment  Specifications  (ADPES),  and  the  Economic 
Analysis  (EA) . 

As  will  be  indicated  in  subparagraph  4.S.1  below,  the  ADSDP  is  pre- 
pared in  part  by  summarizing  the  contents  of  the  subsidiary  action  docu- 
ments. Hence,  the  subsidiary  action  documents  must  be  prepared  before 
the  ADSDP  can  be  prepared.  The  following  subparagraphs  present  prepara- 
tion instructions  for  those  documents. 

4.4.1  Functional  Description  (FD).  The  FD  is  prescribed  in  Department 
of  Defense  Manual  (DODM)  4120. 17-M,  "Automated  Data  Systems  Documentation 
Standards  Manual."  The  DODM  4120. 17-M  Foreword  states  that  the  FD  format 
prescribed  in  the  manual  is  mandatory,  and  further  states  that  the  mili- 
tary departments  and  defense  agencies  may  publish  only  information  that 
supplements  the  provisions  of  the  manual,  and  is  necessary  for  their  own 
specific  requirements. 

The  FD  instructions  in  DODM  4120. 17-M  describe  a document  that  is 
far  wider  in  scope  than  a functional  description  per  se.  The  prescribed 
format  will  produce  a document  that  is  verbose,  diffuse,  redundant,  and 
without  clear  purpose;  and  that  will  not  fit  well  into  the  ADS  Concept 


Phase  logic  delineated  in  Section  3 of  this  report.  Nevertheless,  it 
must  be  used  as  prescribed.  An  attempt  has  been  made,  through  the 
supplementary  instructions  in  Figure  4-03,  to  facilitate  preparation  of 
the  prescribed  FD. 

4.4.2  Data  Requirements  Document  (RD).  The  RD  is  prescribed  in  DODM 
4120. 17-M,  "Automated  Data  Systems  Documentation  Standards  Manual."  As 
in  the  case  of  the  FD  (paragraph  4.4.1,  above),  the  RD  format  is 
mandatory . 

The  RD  instructions  in  DODM  4120. 17-M  are  fairly  straightforward. 
Some  supplementary  instructions  are  given  in  Figure  4-04. 

4.4.3  ADP  Equipment  Specifications  (ADPES) . Figure  4-05  presents  the 
outline  of  the  ADPES.  The  ADPES  is  to  be  prepared  in  accordance  with 
the  general  instructions  in  paragraph  4.1. 

4.4.4  Economic  Analysis  (EA) . Figure  4-06  presents  an  outline  of  the 
EA.  The  EA  is  to  be  prepared  in  accordance  with  the  general  instruc- 
tions in  paragraph  4.1. 

4.5  ADS  Development  Plan  (ADSDP) . The  ADSDP  comprises  a summary  of  the 
problem  to  be  solved  and  the  requirements  to  be  met,  a description  of 
the  ADS  selected  to  satisfy  the  requirements,  a summary  of  the  resources 
required  to  develop  and  implement  the  ADS,  and  a development  and  imple- 
mentation schedule.  Instructions  for  the  body  of  the  ADSDP  are  given  in 
subparagraph  4.5.1. 

The  ADSDP  shall  contain  two  appendixes,  as  described  in  subparagraph 
4.5.2.  The  completed  ADSDP  shall  be  submitted  under  a cover  letter  to 
the  appropriate  approval  authority  identified  by  C4. 

4.5.1  Body  of  Plan.  Figure  4-07  presents  the  outline  of  the  body  of 
the  ADSDP.  The  ADSDP  is  to  be  prepared  in  accordance  with  the  general 
instructions  in  paragraph  4.1. 

4.5.2  Appendixes  to  Plan.  The  ADSDP  shall  contain  at  least  two  appen- 
dixes; additional  appendixes  may  be  added  if  necessary.  The  names  and 
contents  of  the  mandatory  appendixes  are  as  follows: 


15 


a.  Appendix  A,  Subsidiary  Action  Documents.  This  appendix  shall 
contain,  in  order,  the  FD,  RD,  ADPES,  and  EA. 

b.  Appendix  B,  Archival  Material.  This  appendix  shall  contain,  in 
order: 


(1) 

RS 

approval  document 

(2) 

RS 

cover  letter 

(3) 

RS 

(4) 

FS 

approval  document 

(5) 

FS 

cover  letter 

(6) 

FS. 
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REQUIREMENTS  STATEMENT  (RS)  FOR 
AN  INFORMATION  SYSTEM  TO  [state  system  purpose  succinctly] 

SECTION  1.  GENERAL  [Date.] 

1.1  Purpose.  The  purpose  of  this  Requirements  Statement  (RS)  is  to  provide: 

a.  A definitive  written  statement  of  user  requirements. 

b.  A basis  for  deciding  whether  to  commit  the  resources  required 
to  prepare  a Feasibility  Study  (FS)  of  alternative  approaches 
to  meeting  those  requirements. 

1.2  Content.  This  RS  includes  the  following  information: 

a.  Description  of  the  problem  and  its  context  that  generate  the 
apparent  necessity  for  the  information  system. 

b.  Specification  of  the  user  requirements  derived  from  the  problem. 

c.  Substantiation  of  the  validity  of  the  user  requirements. 

d.  Description  of  some  preliminary  and  not  necessarily  exhaustive 
conceptual  approaches  to  satisfying  the  validated  user  require- 
ments. 

e.  Specification  of  the  organization,  resources,  and  schedule 
required  to  prepare  a Feasibility  Study  (FS)  of  alternative 
approaches  to  satisfying  the  user  requirements 

f.  An  estimate  of  the  organization,  resources,  and  time  required 
to  prepare  an  Automated  Data  System  Development  Plan  (ADSDP). 

1.3  Point  of  Contact.  [identify  the  person  or  office  that  is  the  specific 

point  of  contact  for  matters  regarding  this  RS.] 


FIGURE  4-01.  Requirements  Statement  Outline  (Page  1 of  7) 
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SECTION  2.  PROBLEM 


2.1  Problem  Summary.  [Summarize  the  problem  concisely. 1 

2.2  Organizational  Context.  [Specify  the  functional  areas  and  command 
levels  affected  by  the  problem,  and  describe  their  interrelationships.] 

2.3  Annotated  References.  [List  in  some  logical  order  the  documents  that 
bear  directly  on  the  problem,  together  with  succinct  pertinent  annotations.] 

2.4  Problem  Description.  [Describe  the  problem  comprehensively.  Be  sure 
to  include  a concise  description  of  all  the  deficiencies  in  the  present 
situation. ] 

2.5  Existing  System.  [Describe  the  existing  method  or  system,  if  any,  for 
attempting  to  deal  with  the  problem.  If  there  is  none,  so  state.] 


FIGURE  4-01.  Requirements  Statement  Outline  (Page  2 of  7) 
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SECTION  3.  USER  REQUIREMENTS 


[User  requirements  are  derived  from  the  problem.  They  have  the 
characteristic  that,  from  the  user's  point  of  view,  satisfying  them 
would  solve  the  problem.  User  requirements  are  discussed  at  some  length 
in  SRI/NWRC  TN-73,  Automated  Data  Systems  (ADS)  Management  Methodology, 
Task  1 Report:  Objective-Writing  Methodology  for  USMC  ADS  Development, 
July  1977;  particularly  see  paragraph  1.3. 

Do  not  confuse  user  requirements  and  solution  approaches.  For 
example,  a user  does  not  have  a requirement  for  a cathode  ray  tube  (CRT) 
terminal  and  a telecommunications  link  to  a central  computer;  his  re- 
quirement is  actually  tor  a means  of  entering  data  and/or  receiving 
information  at  a specified  location.  A CRT  terminal  is  only  one  of 
several  possible  solution  approaches. 

User  requirements  must  be  specific.  For  example,  a requirement  to 
ensure  continuity  in  logistics  information  systems  support  when  making 
a transition  from  a garrison  to  an  operational  environment  is  not  a 
specific  user  requirement;  it  is  a statement  of  a problem.  Specific 
user  requirements  must  be  derived  from  this  problem. 

User  requirements  should  be  reduced  to  a list  of  statements,  each 
presented  as  simply  and  quantitatively  as  possible.  The  list  should  be 
complete,  and  the  individual  statements  should  be  mutually  exclusive 
insofar  as  practical.] 


FIGURE  4-01.  Requirements  Statement  Outline  (Page  3 of  7) 
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SECTION  4.  VALIDATION  OF  USER  REQUIREMENTS 

[The  decision  makers  will  want  to  satisfy  themselves  that  the 
user  requirements  are  valid.  Therefore,  justification  must  be  provided 
in  this  section  for  each  user  requirement  stipulated  in  Section  3. 
Justification  statements  depend  on  the  situation,  and  may  range  from 
being  objective  (e.g.,  "unless  a parts  order  can  be  delivered  to  a 
supply  source  within  two  hours,  there  is  a high  probability  that  an 
aircraft  will  have  to  be  grounded")  through  subjective  (e.g.,  "the 
DC/S  Manpower  believes  morale  will  be  adversely  affected  unless  personnel 
records  can  be  corrected  in  a specified  way  within  one  week")  to  being 
authoritative  (e.g.,  "the  Commander  orders  it").  The  important  thing 
is  that  there  be  an  identified  reason  for  all  user  requirements. 
Supporting  data  and  analysis  showing  the  extent  to  which  the  user  re- 
quirements are  not  currently  being  met  should  also  be  provided.] 


FIGURE  4-01.  Requirements  Statement  Outline  (Page  4 of  7) 
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SECTION  5.  SOME  PRELIMINARY  CONCEPTUAL  APPROACHES 


[in  this  section,  the  person(s)  preparing  the  RS  may  present 
conceptual  approaches  toward  satisfying  the  user  requirements.  Presen- 
tation of  conceptual  approaches  is  desirable  because  it  will  give  the 
decision  makers  some  relatively  concrete  thou^its  about  possible  end 
products,  and  it  will  provide  a rough  basis  for  the  estimates  in 
Sections  6 and  7.  If  the  RS  preparer(s)  dc  not  have  any  ideas  for 
conceptual  approaches,  it  should  be  so  stated  in  this  section. 

Although  it  was  noted  in  1.2a  that  the  problem  generates  an 
apparent  need  for  an  information  system,  there  may  be  other  solution 
approaches--reorgani zation,  for  example.  These  should  be  considered  in 
this  section.  Further,  even  if  there  is  a real  requirement  for  an  in- 
formation system,  the  information  system  may  not  need  to  be  automated. 

Conceptual  approaches  that  involve  nonautomated  or  automated  infor- 
mation systems  may  be  presented  at  any  level  of  detail  from  sketchy 
information  flow  descriptions  to  system  designs  that  include  generic 
software  and/or  hardware  descriptions.  Software  and  hardware  should  not 
be  specified  by  brand.] 


FIGURE  4-01.  Requirements  Statement  Outline  (Page  5 of  7) 
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SECTION  6.  PLANNING  FOR  FEASIBILITY  STUDY 

6.1  Organization,  [in  this  paragraph,  specify  the  composition  of  the 
Feasibility  Study  (FS)  team.  The  FS  will  be  prepared  by  a team  chaired  by 
a representative  of  the  system  sponsor.  The  exact  composition  of  the  team 
will  depend  on  the  situation,  but  the  following  guidelines  would  usually 
apply.  At  least  one  representative  of  each  user  should  be  assigned  to  the 
team.  One  or  more  representatives  would  be  required  from  the  Information 
Systems  Support  and  Management  Branch  (CCI)  of  the  Command,  Control,  Communi- 
cations and  Computer  Systems  Division.  Other  representatives  such  as  manage- 
ment engineers,  operations  analysts,  and  communications  officers  may  be 
included,  depending  on  the  situation.] 

6.2  Responsibilities.  [This  paragraph  shall  include  a specification  of  the 
responsibilities  of  each  FS  team  member.  In  general,  the  system  sponsor 
would  be  responsible  for  the  overall  FS.  The  system  sponsor  representative, 
user  representatives,  and  CCI  representatives  would  be  responsible  for  delin- 
eating alternative  approaches.  The  CCI  representative  would  be  responsible 
for  determining  technical  feasibility  of  ADS  approaches.  The  sponsor/user 
representatives  would  be  responsible  for  determining  operational  feasibility. 
The  CCI  representative  would  be  responsible  for  developing  life  cycle  cost 
estimates  for  feasible  ADS  approaches.  Other  responsibilities  would  depend 
on  the  particular  situation.] 

6.3  Resource  Requirements.  [This  paragraph  will  present  an  estimate  of  the 
time  required  of  each  FS  team  member  to  perform  his  function.  Any  other 
resource  requirements  (e.g.,  travel  funds)  will  also  be  identified  and  esti- 
ma  ted . ] 

6.4  Schedule.  [This  paragraph  will  present  an  estimated  schedule  for 
preparing  the  FS,  and  will  state  the  estimated  completion  date.] 


FIGURE  4-01.  Requirements  Statement  Outline  (Page  6 of  7) 
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SECTION  7.  PRELIMINARY  PLANNING  FOR  ADS  DEVELOPMENT  PLAN 


7.1  General.  This  section  presents  preliminary  planning  material  relevant 
to  preparation  of  the  ADS  Development  Plan  (ADSDP).  Since  the  magnitude  of 
the  ADSDP  effort  cannot  be  predicted  accurately  until  completion  of  the  FS, 
however,  this  material  is  subject  to  substantial  change.  The  purpose  of 
presenting  this  preliminary  material  is  to  give  the  decision  maker  a broader 
basis  for  deciding  whether  to  proceed  with  the  FS. 

7.2  Organization.  [in  this  paragraph,  specify  the  tentative  composition  of 
the  ADSDP  team.  The  ADSDP  will  be  prepared  by  an  ADSDP  team  which  will  be 
constituted  upon  approval  of  the  FS.  The  team  may  contain  many  of  the  same 
members  as  the  FS  team;  however,  some  may  be  dropped  (e.g.,  management 
engineers)  and  some  may  be  added  (e.g.,  technical  specialists).] 

7.3  Responsibilities.  [This  paragraph  will  tentatively  specify  the  respon- 
sibilities of  each  ADSDP  team  member  with  respect  to  the  various  sections  of 
the  ADSDP.] 

7.4  Schedule.  [This  paragraph  will  present  a tentative  schedule,  keyed  to 
the  FS  approval  date,  for  preparing  and  completing  the  ADSDP.] 


FIGURE  4-01.  Requirements  Statement  Outline  (Page  7 of  7) 
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FEASIBILITY  STUDY  (FS) 

OF  APPROACHES  TO  [state  system  purpose  as  stated  in  title  of  RS] 


SECTION  1.  GENERAL  [Date.] 

1.1  Introduction.  This  Feasibility  Study  (FS)  presents  the  results  of  an 
analysis  of  alternative  approaches  to  satisfying  the  user  requirements  set 
forth  in  "Requirements  Statement  (RS)  for  an  Information  System  to  [State 
purpose  as  stated  in  title  of  RS.]"  dated  [State  date  of  RS.].  The  fact  that 
this  FS  is  being  published  means  that  an  Automated  Data  System  (ADS)  was 
found  to  be  a preferred  alternative  approach.  It  is  emphasized,  however, 
that  automation  was  not  presupposed  when  the  analysis  was  undertaken--in  fact, 
the  designers  of  alternative  approaches  were  specifically  directed  to  consid- 
er nonautomated  approaches  as  well  as  automated  ones.  The  designers  were 
further  directed  to  design  as  many  alternatives  as  practicable. 

1.2  Purposes.  The  purposes  of  this  Feasibility  Study  (FS)  are: 

a.  To  provide  an  analysis  of  broadly  defined  alternative  approaches  to 
satisfying  the  user  requirements  set  forth  in  the  RS  referenced  in 
1.1. 

b.  To  recommend  an  approach  [if  more  than  one  is  selected,  state 
"To  recommend  approaches".]  to  be  analyzed  further  in  an 
Automated  Data  Systems  Development  Plan  (ADSDP). 

1.3  List  of  Alternative  Approaches.  This  FS  addresses  the  following  broadly 
defined,  relatively  dissimilar  alternative  approaches  to  satisfying  the  user 
requirements:  [Enumerate  the  alternatives  in  five  words  or  less.  The  first 
alternative  listed  should  be  the  existing  system,  if  there  is  one.  The 
existing  system  should  be  included  even  if  it  is  patently  deficient.  If 
there  is  no  existing  system,  insert  the  following  sentence  immediately  fol- 
lowing the  title  of  this  paragraph:  "No  system  designed  to  satisfy  the  user 
requirements  currently  exists."  As  an  example  of  the  desired  enumeration 
style,  following  is  an  enumeration  of  four  hypothetical  alternative  ap- 
proaches : 

a.  Existing  system  (manual) 

b.  Automated  centralized  processing 


FIGURE  4-02.  Feasibility  Study  Outline  (Page  1 of  18) 
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c.  Automated  distributed  processing 


d.  Reorganization. 

Since  a Functional  Description  (FD)  will  not  yet  have  been  produced  at 
the  time  FS  is  written,  the  alternative  approaches  in  the  FS  cannot  be  very 
finely  defined;  for  example,  the  FS  cannot  be  used  to  analyze  detailed  design 
tradeoffs  within  a broadly  defined  alternative  approach.] 

1.4  Content:  This  FS  includes  the  following  information: 

a.  Description  of  the  alternative  approach(es)  recommended  for  further 
analysis  in  an  ADSDP 

I 

b.  Description  of  the  existing  approach,  if  any,  and  of  the  other  al-  | 

ternative  approaches  listed  in  paragraph  1.3  above 

' 

c.  Determination  of  the  technical  and  operational  feasibility  of  each  ; 
alternative  approach,  including  a discussion  of  the  underlying  ra-  , 
tionale 

I 

d.  Presentation  of  life  cycle  cost  estimates  for  the  technically  and  | 
operationally  feasible  alternative  approaches 

{ 

e.  Discussion  of  the  benefits  of  the  technically  and  operationally 
feasible  alternative  approaches 

I 

f.  Discussion  of  the  basis  for  selecting  the  recommended  approach(es) . j 

I 

1.5  Functional  Manager(s).  System  Sponsor,  and  User(s). 

1.5.1  Functional  Hanager(s).  [Specify  the  functional  manager(s)  involved. 

If  there  are  more  than  one,  specify  which  is  the  lead  functional  manager.] 

1.5.2  System  Sponsor.  The  system  sponsor  is  the  agent  of  the  functional 
manager(s).  [Specify  organization  and  give  specific  point  of  contact  for 
^matters  regarding  this  FS . ] 

r 

1.5.3  System  User(s).  [Specify  organization(s)  and  give  specific  point(s) 
of  contact  for  matters  regarding  this  FS.] 


FIGURE  4-02.  Feasibility  Study  Outline  (Page  2 of  18) 
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1.6  Problem  and  User  Requirements.  The  problem  and  the  user  requirements 
that  underlie  this  FS  are  fully  described  in  "Requirements  Statement  for  an 
Information  System  to  [state  purpose  as  stated  in  title  of  RS],"  dated 
[state  date  of  RS].  References  applicable  to  the  problem  are  given  in  tha.. 
document . 

1.7  ADS  Guidelines  and  Constraints.  [Here  set  down  a complete  statement  of 
all  recognized  pertinent  guidelines  and  constraints  beyond  those  already  in- 
corporated into  the  user  requirements  contained  in  the  RS  cited  in  paragraph 
1. 6 above.  ADS  guidelines  and  constraints  are  defined  as  requirements -- 
either  directive  or  restrictive--that  reflect  the  influence  of  the  larger 
environment  in  which  the  system  development  is  taking  place.  They  emanate 
from  such  factors  as  policy  guidance,  organizational  arrangements,  mission 
requirements,  resource  considerations,  interoperability  considerations,  ac- 
cepted technical  practice,  and  other  factors  as  well.  For  the  Marine  Corps, 
some  of  the  primary  sources  of  ADS  guidelines  and  constraints  are  the  DOD 
directives,  SECNAV  instructions,  GSA  regulations,  and  Marine  Corps  orders 
relating  to  ADS.  Responsibilities  for  identifying  the  pertinent  ADS  guide- 
lines and  constraints  rest  as  follows: 

a.  With  the  system  sponsor  for  those  governing  functional  area  ac- 
tivities in  the  system  sponsor's  area 

4 

b.  With  the  C organization  for  those  deriving  from  information  sys- 
tem development  policies,  practices,  standards,  and  so  on. 

Pertinent  guidelines  and  constraints  must  be  identified  whether  they 
originate  with  the  Marine  Corps  or  emanate  from  external  authorities.  Some 
(guidelines  and  constraints  may  be  pertinent  to  all  the  alternative  approaches 
jbeing  considered,  while  others  may  pertain  only  to  certain  approaches.  Such 
relationships  should  be  made  clear  in  the  statement  of  guidelines  and  con- 
straints. Responsibility  for  actually  writing  the  statement  of  guidelines 
| and  constraints  rests  with  the  FS  team  in  liaison  with  the  system  sponsor's 
organization  and  the  C^  organization.  This  team  bears  the  further  re- 
sponsibility of  contributing  any  additional  guidelines  and  constraints  known 
to  it,  and  of  conducting  an  analysis  of  the  guidelines  and  constraints  to 
ensure  they  are  as  complete  as  possible.] 

1.8  Other  References.  [List  in  some  logical  order  other  documents  that  bear 
| directly  on  feasibility  determination,  economic  analysis,  and  other  subjects 


FIGURE  4-02.  Feasibility  Study  Outline  (Page  3 of  18) 
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covered  in  this  FS.  Do  not  repeat  the  problem  references  or  other  references 
previously  cited.  References  should  be  annotated  succinctly.] 


FIGURE  4-02.  Feasibility  Study  Outline  (Page  4 of  18) 
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RECOMMENDED  APPROACH (ES) 
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It  is  recommended  that  the  approach  [if  more  than  one  approach  is 

recommended,  use  plurals  as  required]  described  in  this  section  be  develop-  \ 
ed  conceptually  and  analyzed  as  an  approach  to  satisfying  the  user  require- 
ments specified  in  "Requirements  Statement  (RS)  for  an  Information  System 
to  [state  purpose  as  stated  in  title  of  RS.],"  dated  [state  date  of  RS]. 

This  approach  was  selected  from  among  [state  number]  alternative  approaches; 
the  alternatives  that  were  not  selected  are  described  functionally  in 
Section  3. 

Section  4 discusses  the  determination  of  technical  and  operational 
feasibility  of  all  alternative  approaches.  First-cut  cost  (LCC)  estimates 
for  the  recommended  approach  are  recapitulated  in  2.2;  estimates  for  all 
technically  and  operationally  feasible  alternative  approaches  are  presented 
in  Section  5.  The  benefits  associated  with  these  approaches  are  analyzed 
in  Section  6.  A discussion  of  the  selection  process,  including  the  basis 
for  selection  of  the  recommended  approach,  is  presented  in  Section  7. 

2.1  Description  of  Recommended  Approach.  [if  there  is  more  than  one  rec- 
ommended approach,  this  title  will  be  "Description  of  First  Recommended  Ap- 
proach," and  the  subparagraphs  under  2.1  will  cover  the  first  recommended 
approach  only.  The  purpose  of  this  description  is  for  the  determination  of 
feasibility,  as  discussed  in  Section  4.  Generally,  for  this  purpose  the 
approach  need  be  conceived  and  expressed  only  in  broad  conceptual  terms. 
Typically,  the  approach  can  be  described  only  in  such  terms  at  this  early 
stage  of  consideration.  Extensive  analysis  of  the  approach  in  order  to  re- 
fine it  into  a system  design  is  not  called  for  as  part  of  the  feasibility 
determination  process.] 

2.1.1  Concept.  [This  paragraph  will  describe,  to  whatever  extent  is  prac- 
ticable without  extensive  analysis  and  design  effort,  the  overall  concept  of 
how  the  recommended  approach  satisfies  the  user  requirements  stipulated  in 
the  RS.  The  description  will  include  system  objectives  (see  SR1/NWRC-TN-73, 
Automated  Data  Systems  (ADS)  Management  Methodology,  Task  1 Report:  Ob- 
jective-Writing Methodology  for  USMC  ADS  Development,  July  1977;  particular- 
ly see  paragraph  9.1).  It  will  also  include  an  overview  of  system  arch- 
itecture, i.e.,  whether  processing  and  data  bases  are  distributed  or  cen- 
tralized, whether  the  system  is  on-line  or  batch,  etc.  If  it  is  necessary 
to  make  any  assumptions  about  the  system,  they  should  be  stated  explicitly. 

The  description  will  identify  data  inputs  in  general  terms  (they  will  be 
described  in  more  detail  in  2.1.2),  data  entry  points,  processing  steps 
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including  intermediate  actions  by  users,  processing  points,  and  output 
points.  Entry  and  output  points  define  system  interfaces  with  the  environ- 
ment. If  appropriate,  interactions  with  the  environment  that  are  unique  to 
this  approach  may  be  described  briefly  in  general  terms.  The  paragraph 
should  include  a System  Organization  Chart  and  a System  Information  Flow- 
chart as  defined  in  paragraphs  9.2.1  and  9.2,2,  respectively,  of  SECNAVINST 
5233. 1A.] 

j 

2.1.2  Inputs.  [This  paragraph  will  describe  the  data  elements,  records, 
documents,  files,  parameters,  etc.,  introduced  by  user  action  during  system 
operation.  Sources  of  inputs  will  be  identified.] 

2.1.3  Outputs.  [The  data  elements,  records,  documents,  files,  displays, 
or  other  information  will  be  generally  identified  and  described,  together 
with  the  destinations  of  the  outputs.] 

2.1.4  Software.  [This  paragraph  will  describe  the  types  of  operations 
that  must  be  performed  by  software,  e.g.,  file  updating,  search  and  re- 
trieval, order  entry,  inventory  analysis,  etc.  If  specific  computation  ap- 
proaches or  algorithms  can  be  identified  at  this  stage,  they  should  be  des- 
cribed. To  the  extent  applicable  and  possible,  existing  software  (whether 
or  not  it  is  government  property)  that  can  probably  be  used  or  adapted  for 
use  will  be  identified.] 

2.1.5  Equipment.  [The  kinds,  capacities,  and  quantities  of  hardware  re- 
quired for  communications,  input,  storage,  processing,  print,  display,  or 
other  output  will  be  identified  and  described  in  generic  terms.] 

[Note:  If  there  is  more  than  one  recommended  approach,  the  second  should 

be  described  in  2.2,  and  so  on.  The  paragraph  that  now  follows  will  be 
the  last  major  paragraph  in  the  section,  and  will  contain  cost  estimate 
recapitulations  for  all  recommended  approaches.] 

2.2  Cost  Estimate  Recapitulation.  Presented  below  is  the  summary  cost 
estimate  for  the  recommended  approach.  Cost  details  underlying  this  esti- 
mate are  given  in  Section  5.  [Summarize  the  costs  of  the  recommended  ap- 
proach, using  pertinent  material  from  Section  5.] 
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SECTION  3. 


OTHER  APPROACHES 


I 

I 

This  section  describes  the  approaches  to  satisfying  the  user  require- 
ments specified  in  the  RS  that  were  analyzed  but  not  recommended  for  fur- 
ther conceptual  development  and  analysis. 

3.1  Existing  Approach.  [This  paragraph  should  contain  the  same  information 
as  paragraph  2.5  of  the  RS.  Insofar  as  possible,  the  format  of  this  para-  | 
graph  should  follow  the  format  of  paragraph  2.1  above.] 

3.2  Description  of  Second  Nonrecommended  Approach.  [Each  new  alternative 
approach  shall  be  described  in  a major  paragraph.  The  descriptions  shall 
be  in  accordance  with  the  instructions  for  paragraph  2.1.  Major  paragraphs 
shall  be  headed  3,n  Description  of  nth  Nonrecommended  Approach,  with  n rep- 
resenting the  sequential  designator  number  of  the  approach  not  recommended, 
starting  with  n=2 . Subparagraphs  shall  be  headed  as  they  are  in  paragraph 
2.1.  In  many  cases,  subparagraphs  3.n.2  and  3.n.3  will  contain  the  same 
information  as  subparagraphs  2.1.2  and  2.1.3,  respectively.  In  such  cases, 
do  not  repeat  the  earlier  information;  instead,  refer  back  to  the  appropri- 
ate subparagraph.] 
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SECTION  4.  FEASIBILITY  DETERMINATION 

4.1  Purpose  of  Section.  The  purpose  of  this  section  is  to  present  the 
results  of  analyzing  each  alternative  approach  described  in  Sections  2 and 
3 to  determine  whether  it  is  feasible. 

4.2  Meaning  of  Feasible.  "Feasible"  means  capable  of  being  realized.  How- 
ever, "possible"  and  "practicable"  also  mean  capable  of  being  realized. 
Feasible  is  distinguished  from  possible  and  practicable  by  connotation,  as 
follows : 

a.  Possible  implies  that  user  requirements  may  certainly  be 
satisfied  given  the  proper  circumstances 

b.  Practicable  implies  that  user  requirements  may  be  easily 
or  readily  satisfied  by  available  means  or  under  current 
conditions 

c.  Feasible  suggests  what  is  likely  to  work  or  be  useful 
in  achieving  satisfaction  of  user  requirements. 

4.3  Philosophy  of  Feasibility  Analysis.  It  is  apparent  from  4.2  that 
feasibility  determination  is  judgmental.  It  is,  however,  based  on 
analysis.  Feasibility  analysis  is  a process  of  elimination.  Each 
alternative  is  analyzed  with  a view  toward  discovering  any  characteristic 
or  quality  that  would  render  it  infeasible.  If  such  a characteristic  or 
quality  is  found,  the  feasibility  analysis  of  that  approach  may  be 
terminated.  The  rationale  for  adjudging  the  approach  infeasible  must  be 
documented.  If  no  such  characteristic  or  quality  is  found,  the  approach 
is  adjudged  feasible. 

4.4  Aspects  of  Feasibility.  For  analytical  convenience,  feasibility  can 
be  viewed  from  two  aspects,  technical  and  operational.  Technical  feasibil- 
ity involves  equipment,  software,  and  communications  technology  and  their 
integrability , together  with  human  resources,  into  systems.  Operational 
feasibility  involves  the  integrability  of  these  systems  into  the  environ- 
ment. It  should  be  recognized  that  these  aspects  are  not  all  indepen- 
dent. 

Some  feasibility  analysis  techniques  treat  "economic  feasibility"  as 
a third  aspect  of  feasibility.  This  would  not  be  correct  at  the  FS  level, 
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however,  since  the  analysts  who  prepare  the  FS  cannot  assess  the  importance 
of  their  project  relative  to  others  that  may  compete  for  the  same  economic 
resources.  Since  the  FS  analysts  cannot  make  decisions  about  resource  re- 
allocations, they  cannot  determine  economic  feasibility.  In  the  FS , there- 
fore, the  economic  dimension  is  treated  as  a price  tag;  it  is  up  to  higher- 
level  decision  makers  to  determine  whether  and  how  the  price  can  be  paid. 

4.5  General  Feasibility  Criteria.  The  general  feasibility  criteria  given 
below  apply  to  all  Marine  Corps  information  systems,  and  must  be  used  as 
guidelines  in  the  feasibility  analysis. 

4.5.1  General  Technical  Feasibility  Criteria.  Following  are  the  general 
technical  feasibility  criteria  applicable  to  all  Marine  Corps  information 
systems : 

a.  Equipment  must  be  standard  production  equipment.  [The  reason 
for  this  criterion  is  that  the  Marine  Corps  should  not  be  in 
the  information  system  equipment  research  and  development 
business,  and  should  not  serve  as  a test  bed  for  unproven 
equipment.  If  this  criterion  is  modified,  full  justifica- 
tion must  be  provided.] 

b.  Software  must  be  state-of-the-practice . [The  reason  for 
this  criterion  is  analogous  to  that  in  (a)  above.] 

c.  Communications  technology  must  be  state-of-the-practice. 

[The  reason  for  this  criterion  is  analogous  to  that  in  (a) 
above . ] 

d.  The  components  listed  in  a,  b,  and  c must  be  integrable 
using  standard  practice.  [The  reason  for  this  criterion 
is  analogous  to  that  in  (a)  above.] 

4.5.2  General  Operational  Feasibility  Criterion.  The  general  operational 
feasibility  criterion  applicable  to  all  Marine  Corps  information  systems 
is  that  the  system  not  adversely  affect  the  ability  of  the  Marine  Corps, 
or  any  subdivision  thereof,  to  perform  its  mission  effectively,  [if  this 
criterion  is  modified,  full  justification  must  be  provided.] 

i 4.6  Feasibility  Analysis  of  Alternative  Approaches. 

4.6,1  Technical  Feasibility. 
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4.6. 1.1  Issues,  [in  preparing  material  for  this  paragraph,  the  analyst 
must  carefully  analyze  user  requirements,  guidelines  and  constraints,  and 
the  alternative  approaches  in  order  to  determine  technical  feasibility 
issues.  These  are  derived  from  critical  functions  and  any  ancillary  func- 
tions that  might  have  the  potential  of  becoming  choke  points. 

An  example  of  a critical  function  may  be  a requirement  to  provide 
turnaround  within  a specified  time.  This  may  generate  technical  feasibility 
issues  that  involve  system  reliability  and  processing  speed.  These  issues 
should  be  stated  as  quantitatively  as  possible. 

An  example  of  a choke  point  may  be  telecommunications  capacity.  The 
user  requirements  may  not  call  for  telecommunications  capability,  but  some 
of  the  alternative  approaches  may  incorporate  the  need  for  it. 

This  paragraph  should  list  and  discuss  all  technical  feasibility 
issues.  Presented  below  is  a list  of  some  potential  sources  of  technical 
feasibility  issues;  the  list  is  intended  to  be  suggestive,  not  exhaustive, 
and  the  items  on  the  list  are  not  intended  to  be  mutually  exclusive. 

a.  Hardware 


(1)  Central  processor 


(a) 

Processing  speed 

(b) 

Primary  storage  capacity 

(2) 

Storage  (nonprimary) 

(a) 

On-line  auxiliary 

(b) 

Off-line  auxiliary 

(3) 

Other  peripherals 

(a) 

Card/tape  readers/punches 

(b) 

Character  readers 

(c) 

Terminals 

(d) 

Printers 
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(4)  Telecommunications  equipment 


(a)  Communications  processors 

(b)  Modems 

(c)  Multiplexors 

(d)  Data  links 


b.  Software 

(1) 

Operating  system 

(2) 

Functional  packages 

(3) 

Application  software 

c.  Configuration 

(1) 

Reliability 

(2) 

Component  mismatch 

(3) 

Restart  capability 

(4) 

Backup  capability.] 

4.6. 1.2  Analysis.  [Each  of  the  alternative  approaches  should  be  analyzed 
with  respect  to  each  technical  feasibility  issue  in  this  paragraph.  (If 
an  alternative  approach  is  patently  infeasible  with  respect  to  any  issue, 
or  has  been  determined  already  to  be  operationally  infeasible,  the  analysis 
of  that  approach  need  not  be  carried  further.)  If  possible,  summary  charts 
listing  technical  feasibility  issues  horizontally  and  alternative  approaches 
vertically  should  be  included.] 

4.6.2  Operational  Feasibility. 

4.6,2, 1 Issues,  [in  preparing  material  for  this  paragraph,  the  analyst 
must  carefully  analyze  user  requirements,  the  guidelines  and  constraints, 
and  the  alternative  approaches  in  order  to  determine  operational  feasibil- 
ity issues,  which  are  defined  as  operational  factors  that  may  possibly  in- 
teract adversely  with  an  alternative  approach. 
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As  stated  in  paragraph  A. 3,  operational  feasibility  involves  integra-  ( 
bility  into  the  environment.  Environment  has  two  aspects  in  this  context;  j 

the  "local"  environment,  restricted  to  information  processing  and  handling; 
and  the  "global"  environment,  which  includes  the  Marine  Corps  as  a whole 
in  all  of  its  potential  roles  and  missions.  Both  aspects  may  generate 
operational  feasibility  issues. 

This  paragraph  should  list  and  discuss  all  operational  feasibility  i 
issues.  Presented  below  is  a list  of  some  potential  sources  of  operational 
feasibility  issues;  the  list  is  intended  to  be  suggestive,  not  exhaustive, 
and  the  items  on  the  list  are  not  intended  to  be  mutually  exclusive. 

a.  "Local"  factors 

(1)  Data  control  procedures 

(2)  Backup  procedures 

(3)  Restart  procedures 

(4)  Security  procedures 

(5)  Scheduling 

(6)  Maintenance  and  support  requirements 

I 

b.  "Global"  factors 

(1)  Expansibility  for  mobilization 

(2)  Deployability 

(3)  Vulnerability 

(4)  Manning  requirements  (e.g.,  civilian  vs.  military) 

(5)  Backup  capability 

(6)  Degraded  mode  operation  (e.g.,  with  electronic  data 
links  inoperative).] 
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4. 6. 2. 2 Analysis.  [Each  of  the  alternative  approaches  should  be  analyzed 
with  respect  to  each  operational  feasibility  issue  in  this  paragraph.  (If 
an  alternative  approach  is  patently  infeasible  with  respect  to  any  issue, 
or  has  been  determined  already  to  be  technically  infeasible,  the  analysis 
of  that  approach  need  not  be  carried  further.)  If  possible,  summary  charts 
listing  ooerational  feasibility  issues  should  be  included  horizontally  and 
alternative  approaches,  vertically.] 

4. 7 Summary. 

4.7.1  Feasible  Approaches.  [List  the  approaches  determined  to  be  techni- 
cally and  operationally  feasible  on  the  basis  of  the  feasibility  analyses 
in  4.6.  ] 

4.7.2  Infeasible  Approaches.  [List  the  approaches  determined  to  be  in- 
feasible on  the  basis  of  the  feasibility  analyses  in  4.6  and  briefly  sum- 
marize the  reasons(s).] 
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SECTION  5.  LIFE  CYCLE  COST  ANALYSIS 

[The  contents  of  this  section  and  the  next  section  constitute  an  eco-  | 
nomic  analysis  as  prescribed  in  DOD  Instruction  7041.3.  This  economic 
analysis  must  not  be  confused  with  the  EA  (the  ADSDP  subsidiary  action  doc- 
ument discussed  in  paragraph  4.4.4  of  the  text),  although  the  same  techni-  ! 
que  is  used  for  both. 

I 

The  differences  between  this  economic  analysis  and  the  EA  are  in  the  ! 
level  of  detail  and  in  the  degree  of  similarity  among  alternatives.  The 
economic  analysis  in  these  sections  addresses  relatively  dissimilar  alter- 
natives in  relatively  coarse  detail,  whereas  the  EA  addresses  relatively 
similar  alternatives  in  relatively  fine  detail.  The  reason  for  this  is 
that  the  economic  analysis  in  these  sections  will  help  lead  to  a preferred  i 
alternative  approach  for  further  development;  the  EA  will  be  chiefly  con- 
cerned with  cost  performance  tradeoffs  within  that  approach. 

This  economic  analysis  is  presented  in  two  sections  in  order  to  sep- 
arate cost  estimation  from  the  process  of  selecting  the  preferred  alterna- 
tive approach(es) . This  section  contains  the  cost  estimation  portion  of 
the  economic  analysis. 

The  economic  analysis  in  these  sections  should  be  developed  and  pre- 
sented in  conformance  with  General  Guidelines  B and  C in  Enclosure  2 to 
DODI  7041.3  dated  October  18,  1972.  The  guidelines  that  are  particularly 
applicable  to  this  section  are  B.l  through  B.4  and  B.7.  Supplementary 
comments  applicable  to  these  guidelines  are  given  below. 

a.  B.l  Objectives.  These  are  given  in  Section  2 of  the  FS  and 
need  not  be  repeated  here. 

b.  B.2  Assumptions.  Technical  assumptions  are  covered  in  paragraph 
2.1  of  the  FS  and  need  not  be  repeated.  Any  other  assumptions 
should  be  stated  explicitly  in  this  section. 

c.  B.3  Alternatives.  These  are  covered  in  section  2 of  the  FS  and 
need  rot  be  repeated. 

d.  B.4  Cost  Analysis.  In  addition  to  the  material  in  the  guide- 
lines, SRI/NWRC-TN-72 , Automated  Data  Systems  (ADS)  Management 
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Methodology,  Task  2 Report:  Resource  Requirements  Estimatlnj 
Methodology , May  1977,  will  be  useful  in  developing  cost 
estimates . 

B.7.  Risk/Uncertainty  Analysis.  The  analysis  portion  of  this 
guideline  applies  to  Section  7 of  the  FS ; however,  the  material 
on  parametric  cost  estimation  applies  to  this  section.  Para- 
metric cost  estimates  and  probability  distributions  of  costs 
should  be  derived  whenever  possible.] 
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SECTION  6. 


BENEFITS  ANALYSIS 


[As  pointed  out  in  General  Guideline  B.5  in  Enclosure  2 to  DODI  7041.3, 
benefits  must  be  taken  into  account  in  an  economic  analysis.  Negative  ben- 
efits ( "dysbenefits"  or  detrimental  impacts)  have  already  been  addressed  in 
Section  4,  "Feasibility  Determination". 

"Benefits,"  for  this  purpose,  are  beneficial  effects  on  the  mission- 
effectiveness of  the  USMC  or  any  of  its  subdivisions  that  were  not  included 
in  the  user  requirements.  Examples  are  the  proposed  system's  expandability, 
potential  adaptability  to  other  uses,  increased  responsiveness,  likelihood 
of  successful  implementation,  commonality  with  other  systems,  potential  for 
enhancement  of  combat  readiness  and  of  morale,  potential  cost  savings  in 
non-user  agencies,  and  so  on. 

All  benefits  that  can  be  identified  should  be  listed  and  discussed 
for  each  technically  and  operationally  feasible  alternative. 

Benefits  should  be  quantified  wherever  possible.  Care  should  be  taken 
to  describe  and  analyze  non-quantif iable  benefits  in  realistic  terms;  it 
is  all  too  easy  to  indulge  in  wishful  thinking  in  this  area.] 
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SECTION  7. 


THE  SELECTION  PROCESS 


7.1  Purpose  of  Section.  The  purpose  of  this  section  is  to  present  the 
basis  for  selecting  the  recommended  approach(es)  described  in  Section  2. 

7.2  The  Process.  [Selection  of  a recommended  approach  from  among  the  al- 
ternatives is  a judgmental  process.  General  Guidelines  B.5  through  B.9  in 
Enclosure  2 to  DODI  7041.3  apply  to  the  selection  process.  The  material  in 
the  following  paragraphs  supplements  the  general  guidelines. 

In  order  to  be  considered  for  selection  as  a preferred  alternative 
approach,  a system  must  satisfy  the  user  requirements  and  be  technically  and 
operationally  feasible. 

For  the  alternative  approaches  that  qualify  to  be  considered  for 
selection,  the  following  ranking  rules  shall  apply: 

a.  Equal  Costs  - Unequal  Benefits.  When  alternatives  have  the  same 
discounted  cost,  the  alternative  with  the  greatest  benefits  is 
preferred . 

b.  Unequal  Costs  - Equal  Benefits.  When  alternatives  have  the  same 
level  of  benefits,  the  alternative  with  the  lowest  discounted 
cost  is  preferred. 

c.  Unequal  Costs  - Unequal  Benefits.  When  alternatives  have  both 
unequal  discounted  costs  and  unequal  levels  of  benefits,  the  fol- 
lowing rules  apply: 

(1)  If  the  alternative  with  the  lowest  discounted  costs  also  pro- 
vides the  highest  level  of  benefits,  it  is  the  preferred  al- 
ternative. 

(2)  Alternatives  whose  costs  and  benefits  excted  those  of  the 
lowest  cost  alternative  may  be  selected  as  the  preferred  al- 
ternative only  if  their  additional  cost  is  clearly  justified 
by  the  estimated  value  of  their  additional  benefits  and  fully 
documented  in  this  section. 

If  special  considerations  require  the  selection  of  an  alternative  by 


FIGURE  4-02.  Feasibility  Study  Outline  (Page  17  of  18) 


40 


other  than  the  above  prescribed  rules,  the  considerations  must  be  com- 
pelling, defensible,  and  fully  documented  in  this  section. 

In  some  cases--for  example,  when  development  involves  considerable 
risk  or  uncertainty--it  may  be  desirable  to  select  more  than  one  recommended 
approach.  This  procedure  should  be  minimized  because  it  will  significantly 
increase  the  costs  associated  with  preparation  of  the  ADS  Development  Plan. 
If  more  than  one  approach  is  recommended,  full  justification  must  be  pro- 
vided for  the  decision  to  do  so.] 
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[These  supplementary  Instructions  refer  to  the  correspondingly  numbered  FD 
paragraphs  described  in  Figure  2-01  of  DOOM  4120-17-M.  DODM  4120. 17-M  does 
not  prescribe  a title  or  date;  they  should  be  added  as  shown  prior  to  Sec- 
tion 1.] 

FUNCTIONAL  DESCRIPTION  (FD)  FOR  A SYSTEM  TO 
[State  system  purpose  as  stated  in  title  of  RS] 

[Date. ] 

SECTION  1.  GENERAL 

1.1  Purpose  of  Functional  Description.  [Since  DODM  4120. 17-M  states  that 
the  prescribed  wording  may  be  modified  when  appropriate,  use  the  wording 
given  subsequently.] 

The  purposes  of  this  Functional  Description  for  [state  system  purpose 
as  state  in  titles  of  RS  and  FS]  are: 

a.  To  describe  functionally  the  ADS  designed  to  satisfy  the  user 
requirements  set  forth  in  the  RS  referenced  in  1.2a,  the  de- 
sign having  been  based  on  the  preferred  alternative  approach 
selected  in  the  FS  referenced  in  1.2b  and  refined  in  the  EA 
referenced  in  1.2c. 

b.  To  provide  the  other  information  (or  references  to  it)  re- 
quired to  be  included  in  an  FD  by  DOD  Manual  4120. 17-M. 

1.2  Project  References.  This  FD  is  part  of  Appendix  A to  an  ADS  Develop- 
ment Plan  (ADSDP).  The  general  nature  of  the  computer  programs  to  be  dev- 
eloped is  indicated  in  references  a and  b below,  which  are  part  of  Appendix 
B to  the  ADSDP.  System  functional  manager(s),  sponsor,  and  user(s)  are 
specified  in  the  body  of  the  ADSDP.  Specific  references  are: 

a.  [The  RS] 

b.  [The  FS] 

c.  [The  EA] 


FIGURE  4-03.  Functional  Description  Supplementary  Instructions  (Page  1 of  4) 
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FIGURE  4-03.  Functional  Description  Supplementary  Instructions  (Page  2 or  4) 


SECTION  2. 


SYSTEM  SUMMARY 


2.1  Background.  [Much  of  this  material  can  be  provided  by  reference  to 
Section  2 of  the  RS.] 

2.2  Objectives.  [The  DODM  4120. I7-M  instructions  for  this  paragraph  are 
not  meaningful  because  they  use  the  terms  objectives,  requirements  and 
goals  synonymously;  because  the  relationship  of  the  second  sentence  to  ob- 
jectives is  not  apparent;  and  because  the  third  sentence  has  nothing  to  do 
with  objectives.  For  instructions  in  writing  operative  objectives,  see 
Section  5 of  this  report  and  SRI/NWRC-TN- 73 , Automated  Data  Systems  (ADS) 
Management  Methodology,  Task  1 Report:  Objective-Writing  Methodology  for 
USMC  ADS  Development,  July  1977.] 

2.3  Existing  Methods  and  Procedures.  [Much  of  this  material  can  be  pro- 
vided by  reference  to  paragraph  2.5  of  the  RS.] 

2.4  Proposed  Methods  and  Procedures.  [No  supplementary  comments.] 

2.4.1  Summary  of  Improvements.  [Be  concise;  avoid  verbosity  and  sales- 
manship . ] 

2.4.2  Summary  of  Impacts.  [Be  concise.  (This  guideline  also  applies  to 
all  the  subparagraphs. ) ] 

2.5  Expected  Limitations.  [No  supplementary  comments.] 

SECTION  3.  DETAILED  CHARACTERISTICS 

[No  supplementary  comments.] 

SECTION  4.  ENVIRONMENT 

[No  supplementary  instructions.] 

SECTION  5.  COST  FACTORS 

[The  instructions  for  this  section  call  for  presentation  of  material 
that  is  covered  in  the  FS  and  EA.  To  avoid  redundancy,  they  should  be 
referenced  rather  than  repeating  the  information,] 

FIGURE  4-03.  Functional  Description  Supplementary  Instructions  (Page  3 of  4) 
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SECTION  6. 


DEVELOPMENTAL  PLAN 


As  previously  stated  in  paragraph  1.2,  this  FD  is  part  of  an  ADS 
Development  Plan.  In  other  words,  the  FD  is--and  logically  should  be-- 
part  of  a developmental  plan,  rather  than  the  other  way  around.  For  the 
developmental  plan,  refer  to  the  ADSDP  of  which  this  FD  is  part  of  Appen- 
dix A. 
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[These  supplementary  instructions  refer  to  the  correspondingly-numbered 
paragraphs  described  in  Figure  2-02  of  DO DM  4120. 17-M.  DO DM  4120. 17-M  does 
not  prescribe  a title  or  date;  these  should  be  added  as  shown  prior  to  Sec- 
tion 1.] 

DATA  REQUIREMENTS  DOCUMENT  (RD)  FOR  A SYSTEM  TO 
[State  system  purpose  as  stated  in  title  of  RS.] 

[Date . ] 

SECTION  1.  GENERAL 

1.1  Purpose  of  Data  Requirements  Document.  [No  supplementary  instructions.] 

1.2  Project  References.  [The  requirement  for  this  information  is  complete- 
ly redundant  since  it  is  also  required  in  the  FD.  To  satisfy  the  require- 
ment, copy  paragraph  1.2  of  the  FD. ] 

1.3  Modification  of  Data  Requirements.  [No  supplementary  instructions.] 

SECTION  2.  DATA  DESCRIPTION 

[No  supplementary  instructions.] 

SECTION  3.  USER  SUPPORT  FOR  DATA  COLLECTION 

[The  "hardware  device"  in  3.1b  should  be  specified  only  in  generic 
terms,  not  by  brand  name. 

The  definition  of  "expansion  factor"  in  3.1h  is  incorrect.  The  ex- 
pansion factor  is  not,  as  stated,  "to  be  added  to  the  maximum  number  of 
entries".  Instead,  it  is  the  factor  by  which  the  maximum  number  of  entries 
is  to  be  multiplied.  With  this  definition,  the  example  given  in  3.1h  will 
be  correct.] 


FIGURE  4-04.  Data  Requirements  Document  Supplementary  Instructions  (Page  1 of  1) 
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ADP  EQUIPMENT  SPECIFICATIONS  (ADPES)  FOR  A SYSTEM  TO 
[state  system  purpose  as  stated  in  title  of  RS.] 

iDate . ] 

SECTION  1.  GENERAL 

1.1  Purpose.  The  purpose  of  this  ADP  Equipment  Specification  (ADPES)  is  to 
provide  preliminary  information  to  those  concerned  with  procurement  of  ADP 
equipment  so  that  they  can  initiate  their  activities. 

1.2  Content.  This  ADPES  contains  a concise  list,  in  generic  terms  , of  the 
ADP  equipment  that  is: 

a.  Required  to  operate  the  ADS  described  in  the  FD  cited  in  1.3  below; 
and 

b.  Not  currently  in  service  or  programmed  or  planned  to  be  put  in 
service . 

1.3  References.  This  ADPES  is  part  of  Appendix  A to  the  ADS  Development 
Plan  with  the  same  title.  The  entire  plan  should  be  referred  to  for  com- 
plete information  about  the  system.  This  ADPES  relates  most  directly  to 
paragraph  4.1  of  the  Functional  Description  (FD),  which  is  also  part  of 
Appendix  A to  the  plan. 

SECTION  2.  EQUIPMENT  SPECIFICATIONS 

[This  section  shall  provide  a generic  description  of  the  capabilities 
of  the  equipment  that  is  required  for  the  operation  of  the  ADS  and  that  is 
not  currently  in  service  or  programmed  or  planned  to  be  put  in  service.  A 
suggestive  but  not  exhaustive  guideline  for  equipment  to  be  described  fol- 
lows: 

a.  Processor(s) , including  number  of  each  on/off-line  and  size  of 
internal  storage. 

b.  Storage  media,  including  number  and  characteristics  of  disk  units, 
tape  units,  etc. 


FIGURE  4-05.  ADP  Equipment  Specifications  Outline  (Page  1 of  2) 
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FIGURE  4-05.  ADP  Equipment  Specifications  Outline  (Page  2 of  2) 
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ECONOMIC  ANALYSIS  (EA)  OF  AN  ADS  TO 
[State  system  purpose  as  stated  in  title  of  RS] 


[Date. ] 

SECTION  1.  GENERAL 

1.1  Purpose.  The  purpose  of  this  Economic  Analysis  (EA)  document  is  to 
present  the  results  of  a detailed  economic  analysis,  performed  in  compliance  1 
with  DOD  Instruction  7041.3,  of  an  ADS  to  [State  system  purpose  as  stated  in  i 
title.]. 

I 

1.2  Context.  This  EA  is  part  of  Appendix  4 to  an  ADS  Development  Plan 
(ADS DP)  for  an  ADS  to  [state  system  purpose  as  stated  in  title  of  RS]. 

This  ADS  was  designed  to  satisfy  the  validate.  ier  requirements  stated  in 
the  Requirements  Statement  (RS)  referred  to  in  paragraph  1.3a  below.  The 
selection  was  made  on  the  basis  of  the  Feasibility  Study  (FS)  referred  to 
in  paragraph  1.3b  below.  That  FS  contained  an  economic  analysis  of  broadly 
defined,  rather  dissimilar  alternatives,  one  of  which  was  selected  as  the 
preferred  alternative  approach  to  satisfying  the  user  requirements.  The  se- 
lected ADS,  refined  on  the  basis  of  the  analysis  herein,  is  described  in  the 
Functional  Description  (FD)  referred  to  in  paragraph  1.3c  below.  This  FD 

is  also  a part  of  Appendix  A to  the  ADSDP, 

1.2.1  Objectives.  The  objectives  of  the  ADS,  required  by  DODI  7041.3  to 
be  stated  in  an  economic  analysis,  are  given  in  paragraph  2.2  of  the  FD. 

1.2.2  Assumptions.  [State  any  assumptions  made.  If  indicated,  reference 
may  be  made  to  FD  or  to  paragraph  2.1  of  the  FS  for  technical  assumptions.] 

1.2.3  Alternatives.  As  stated  above,  broadly  defined,  relatively  dis- 
similar alternatives  were  addressed  in  the  FS,  and  one  was  selected 

as  the  preferred  approach. [Use  plurals  as  necessary  if  there  is  more  than 
one  preferred  alternative  approach.]  The  alternatives  considered  in  this 
EA  are  narrowly  defined  alternatives--for  example,  design  tradeoffs — within 
the  broadly  defined  preferred  alternative  approach.  They  are  all  variations 
of  the  specific  ADS  approach  described  in  Section  3 of  the  FD.  The  present- 
ly existing  system  was  also  addressed  in  the  FS ; its  costs  are  recapitulat- 
ed in  this  EA  for  easy  reference.  [if  there  is  no  existing  system,  replace 
the  preceding  sentence  with  a sentence  that  so  states.]  The  alternatives 
considered  in  this  EA  are  described  below.  [Add  a subparagraph  1.2.3. 1, 


FIGURE  4-06.  Economic  Analysis  Outline  (Page  1 of  2) 
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1.2. 3. 2,  etc.,  for  each  alternative.  Describe  the  alternatives  in  terms  ot 
their  unique  features,  being  as  concise  as  practicable.  Note  that  "alterna- 
tives" should  be  broadly  construed;  for  example,  it  may  refer  to  alterna- 
tive development  schedules  for  the  same  technical  system.] 

1.3  References.  The  following  references  are  directly  relevant  to  this  EA: 

a.  [The  RS] 

b.  [The  FS] 

c.  [The  FD] 

d.  [The  ADPES,  it  is  relevant]. 

SECTION  2.  COST  DEVELOPMENT 

[The  material  in  this  section  should  be  developed  and  presented  accord- 
ing to  General  Guidelines  B.4,  B.7  (parametric  cost  estimation  portion  only), 
and  C in  Enclosure  2 to  DODI  7041.3  dated  October  18,  1972.  In  addition  to 
the  guidelines,  SRI/NWRC-TN-72,  Automated  Dated  Systems  (ADS)  Management 
Methodology,  Task  2 Report:  Resource  Requirements  Estimating  Methodology , 

May  1977,  and  Section  6 of  this  report,  will  be  very  useful  in  developing 
cost  estimates.] 

SECTION  3.  COST-VALUE  ANALYSIS 

[The  material  in  this  section  should  be  developed  and  presented  accord- 
ing to  General  Guidelines  B.5  through  B.9  and  C in  Enclosure  2 to  DODI  7041.2 
dated  October  18,  1972.  "Value,"  as  used  here,  includes  both  quantifiable 
and  non-quantif iable  factors  such  as  performance,  work  measures,  benefits, 
and  utility.  Because  of  the  inclusion  of  non-quantifiable  factors,  the 

cost-value  analysis  must  be  judgmental  to  a certain  extent.] 

SECTION  4.  CONCLUSION 

[State  which  of  the  alternatives  in  paragraph  1.2.3  was  selected  as 
the  best  system  design  for  inclusion  in  the  FD  and  ADPES,  and  state  the 
reasons  (which  should  be  based  on  the  analysis  in  Section  3.)] 


FIGURE  4-06.  Economic  Analysis  Outline  (Page  2 of  2) 
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AUTOMATED  DATA  SYSTEM  (ADS)  DEVELOPMENT  PLAN  FOR  A SYSTEM  TO 
[State  system  purpose  as  stated  in  title  of  RS] 

[Date. ] 

SECTION  1 • GENERAL 

1.1  Purpose.  The  purpose  of  this  ADS  Development  Plan  (ADSDP)  is  to  pro- 
vide decision  makers  with  a basis  for  deciding  whether  to  approve  for  devel 
opment  and  implementation  and  ADS  to  [state  system  purpose  as  stated  in 
title] . 

1.2  Content.  This  ADSDP  includes  the  following  information: 

a.  A summary  of  the  problem  that  generated  the  requirement  for  an  ADS 

b.  A summary  of  the  specific  user  requirements  that  must  be  satis- 
fied by  the  ADS. 

c.  A statement  of  the  ADS  objectives. 

d.  A summary  of  the  characteristics  of  the  ADS  designed  to  satisfy 
the  user  requirements  and  the  system  objectives. 

e.  A resource-time  schedule  for  developing  and  implementing  the  ADS. 

f.  A designation  of  responsibilities  for  achieving  the  ADS. 

g.  Two  appendices  [or  more  if  required],  as  follows: 

(1)  Appendix  A,  Subsidiary  Action  Documents.  This  appendix 
contains  the  action  documents  that  directly  support  this 
plan.  In  order  of  appearance,  they  are  the  FD,  the  RD, 
the  ADPES,  and  the  EA. 

(2)  Appendix  B,  Archival  Material.  This  appendix  contains, 
in  order,  the  RS  approval  document,  the  RS  cover  letter, 
the  RS , the  FS  approval  document,  the  FS  cover  letter,  and 
the  FS. 


FIGURE  4-07.  ADS  Development  Plan  Outline  (Page  1 of  4) 


I 


1.3  Functional  Manager(s),  System  Sponsor,  and  User(s) . 

1.3.1  Functional  Manager (s).  [Specify  the  functional  managers  involved.  If 
there  are  more  than  one,  specify  which  one  is  the  lead  functional  manager.] 

1.3.2  System  Sponsor.  The  system  sponsor  is  the  agent  of  the  functional 
manager(s).  [Specify  organization  and  give  specific  point  of  contact  for 
matters  regarding  this  ADSDP.] 

1.3.3  System  User(s) . [Specify  organization(s)  and  give  specific  point(s) 
of  contact  for  matters  regarding  this  ADSDP.] 

1.4  References.  Annotated  references  that  bear  directly  on  the  problem 
are  given  in  paragraph  2.3  of  the  RS  (see  Appendix  B).  ADS  guidelines  and 
constraints  are  covered  in  paragraph  1.7  of  the  FS  (see  Appendix  B);  ref- 
erences pertinent  to  feasibility  determination  and  economic  analysis  are 
given  in  paragraph  1.8  of  the  FS.  All  the  documents  in  Appendix  A are 
directly  pertinent  to  this  ADSDP. 


SECTION  2. 


PROBLEM  SUMMARY 


[in  this  section,  summarize  the  problem  concisely.  It  may  be  possible 
to  repeat  paragraph  2.1  of  the  RS  and  reference  paragraph  2.4  of  the  RS 
for  more  detailed  information;  the  preparer  should  use  his  judgment  as  to 
whether  this  is  appropriate.] 


SECTION  3. 


USER  REQUIREMENTS  SUMMARY 


[Summarize  succinctly  the  user  requirements  in  Section  3 of  the  RS. 
Include  a statement  that  these  requirements  were  validated,  and  refer  to 
Section  4 of  the  RS.] 

SECTION  4.  ADS  OBJECTIVES 

[Copy  paragraph  2.2  of  the  FD.] 


FIGURE  4-07.  ADS  Development  Plan  Outline  (Page  2 of  4) 
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ADS  DESCRIPTION 
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SECTION  5. 

[Summarize  Section  3 of  the  FD  succinctly.  Consider  all  design  fea- 
tures, but  do  not  make  the  section  any  longer  than  absolutely  necessary; 
refer  the  readers  to  Section  3 of  the  FD  for  complete  details.] 


SECTION  6.  RESOURCES  AND  SCHEDULE 

This  section  presents  a detailed  time  schedule  for  employing  the  re- 
sources enumerated  in  the  EA  (see  Appendix  A).  Time  is  itself  a resource; 
it  is  often  possible  to  make  tradeoffs  between  time  and  the  other  resources, 
which  chiefly  constitute  manpower  and  equipment. 

In  planning  for  this  ADS,  it  was  [or  "was  not",  as  appropriate]  possi- 
ble to  make  tradeoffs  between  time  and  the  other  resources,  [if  it  was 
possible,  insert  the  following  sentence:  "Alternatives  involving  time  trade- 
offs are  discussed  in  the  EA."  If  it  was  not  possible,  explain  why;  for  ex- 
ample, the  time  schedule  may  have  been  dictated  by  a deadline  established 
and  validated  in  the  RS. 

In  the  remainder  of  this  section,  present  a schedule  of  tasks  and 
subtasks,  the  resources  consumed  in  performing  the  tasks  and  subtasks,  and 
"milestone"  dates  that  mark  the  completion  of  tasks  and  possibly  of  subtasks. 

"Tasks"  are  logically  related  activities  directed  toward  a single,  tan- 
gible goal.  For  convenience,  it  is  sometimes  possible  and  desirable  to  sub- 
divide tasks  into  "subtasks,"  each  of  which  has  a single  tangible  goal. 
Subtasks  have  the  characteristic  that,  when  the  goals  of  all  the  subtasks 
within  a task  have  been  achieved,  the  goal  of  the  task  is  thereby  also 
achieved.  The  planner  who  subdivides  a task  must  assure  that  this  rule  is 
adhered  to. 

An  example  of  a task  is  the  writing  of  program  specifications  for 
a major  module  of  the  ADS.  If  this  module  comprises  several  programs,  the 
writing  of  program  specifications  for  the  individual  programs  may  represent 
subtasks.  In  this  case,  an  integration  subtask  would  probably  also  be  re- 
quired. When  all  the  program  specification  writing  subtasks  and  the  inte- 
gration subtask  are  complete,  the  task  is  automatically  complete. 


FIGURE  4-07.  ADS  Development  Plan  Outline  (Page  3 of  4) 
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Task  and  subtask  definitions  used  in  the  ADSDP  must  be  consistent  with 
those  in  the  EA.  This  will  enable  the  basis  for  estimating  the  required 
resources  to  be  traced. 

"Milestones"  are  used  to  mark  achievement  points  that  are  of  particular 
significance  to  the  planner  or  manager.  In  order  to  determine  that  a mile- 
stone has  been  reached,  some  measurable  product  must  have  been  produced. 

This  implies  that  a milestone  can  be  established  only  at  the  end  of  a task 
or  subtask.  (In  practice,  milestones  are  usually  established  only  at  the 
end  of  selected  tasks,  not  subtasks,  but  this  is  a matter  of  judgment  for 
the  planner.)  Examples  of  the  use  of  milestones  are  to  mark  points  select- 
ed for  management  review  or  for  transfer  of  responsibilities. 

Times  used  in  the  schedule  may  be  stated  either  absolutely  (calendar 
dates)  or  relative  to  a reference  time  such  as  the  initiation  of  the  Anal- 
ysis and  Design  Phase. 

The  schedule  should  be  displayed  on  a horizontal  bar  chart  with  time 
on  the  horizontal  axis.  The  chart  may  be  supplemented  with  tables,  explan- 
atory text,  and  footnotes,  as  required.  Critical  path  or  PERT-type  dia- 
grams should  be  included  if  possible;  however,  if  a full-blown  PERT  analysis 
is  made,  the  fine  details  should  be  relegated  to  an  appendix. 

The  schedule  must  include  all  tasks  required  to  develop  and  implement 
the  ADS.  Partial  schedules  are  not  acceptable.] 

SECTION  7.  RESPONSIBILITIES 

[in  this  section,  specify  the  organization  that  is  responsible  for  each 
task  and  subtask.  Although  more  than  one  organization  may  participate  in  a 
task  or  subtask,  only  one  will  have  the  responsibility.  Responsibility  may 
be  transferred  only  when  milestones  have  been  reached.  Since  reaching  a 
milestone  means  that  a measurable  product  has  been  produced,  waiting  until 
then  to  transfer  responsibility  assures  a defined  interface  for  the 
transfer. 

If  management  review  points  are  included  in  the  schedule,  this  section 
should  also  designate  the  organizations  responsible  for  the  reviews.] 


FIGURE  4-07.  ADS  Development  Plan  Outline  (Page  4 of  4) 
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SECTION  5.  OBJECTIVE-WRITING  METHODOLOGY  FOR  USMC  ADS  DEVELOPMENT 


5.1  ADS  Objectives  and  Their  Use.  Objective-writing  is  an  optional 
tool  to  assist  developers  to  perform  tasks  and  generate  information 
required  by  the  Concept  Phase  action  document  preparation  procedures. 

It  is  not  a mandatory  requirement  for  ADS  management.  Specifically, 
objective-writing  is  a technique  for  defining  the  objectives  of  an  ADS 
being  developed  to  meet  a user’s  perceived  information  processing  require- 
ments expressed  in  the  user's  own  terms. 

An  ADS  objective  is  any  feature,  property,  characteristic,  or 
ability  specified  in  advance  as  being  desired  in  an  ADS  proposed  for 
development . 

A set  of  ADS  objective  statements  is  a set  of  statements  applying 
to  the  ADS  as  a whole,  with  each  expressing  one  or  more  ADS  objectives 
for  the  system.  It  constitutes  the  most  general,  or  top-most,  level 
of  system  specification. 

ADS  objectives  serve  three  functions  in  the  development  process. 
First,  they  guide  the  design  decisions  made  by  the  working  system 
designers.  As  specifications,  the  ADS  objectives  define  entities, 
relationships,  and  characteristics  that  must  be  created  by  the  designers. 
The  objectives  direct  and  constrain  design  choices.  Second,  ADS  objec- 
tives aid  the  decision-makers  who  must  approve  or  disapprove  the  concept 
of  the  proposed  system.  Third,  as  specifications,  the  objectives  provide 
a basis  for  evaluating  the  result  produced  by  system  development. 

Experience  with  past  ADS  developments  both  outside  and  within  the 
Marine  Corps  illustrates  the  inherent  problems  with  specifying  ADS 
objectives,  as  follows: 

• Objectives  are  rarely  stated  explicitly 

• Objectives,  if  stated,  do  not  fully  reflect  user  requirements 

• Objectives  are  often  contradictory 

• Fulfillment  of  objectives  cannot  be  adequately  determined. 

The  Objective-Writing  Methodology  provides  a systematic  approach  to 
producing  a body  of  objective-statements  that  avoid  these  hazards. 
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Objective-writing  is  applied  in  the  Concept  Phase  to  the  selected 
ADS  approach  or  approaches  that  were  recommended  in  the  Feasibility  Study. 
ADS  objectives  for  each  approach  must  be  developed  for  inclusion  in  the 
FD  portion  of  the  ADSDP.  Objective-writing  can  also  be  useful  in  the 
Feasibility  Study,  where  frequently  explicit  objectives  must  be  developed 
for  the  hypothetical  alternative  approaches  whose  feasibility  is  being 
investigated. 

5.2  Objective-Writing  Methodology 

5.2.1  Conceptual  Approach  of  the  Method.  This  methodology  represents  a 
common-sense,  manual  approach  to  the  problem  of  developing  explicit  ADS 
objectives.  It  is  based  on  the  concept  of  logically  investigating  and 
enhancing  certain  intrinsic  serviceability  properties  of  objective 
statements.  Those  properties  are  defined  in  Table  5-01. 

This  methodology  consists  of  six  distinct  operational  procedures: 

a.  Trial  Objective  Statements 

b.  Requirements  Restatement 

c.  Requirements  Mapping 

d.  Pairwise  Checks  for  Consistency,  Independence  and  Comparability 

e.  Check  for  Simplicity 

f.  Determinability  Analysis. 

They  are  essentially  independent  and  can  be  employed  in  any  convenient 
order  and  repeated  as  often  as  they  are  productive  of  refinements  in  the 
objectives . 

5.2.2  Expected  Results.  The  primary  outcome  of  an  application  of  the 
methodology  is  the  production  of  a completed  body  of  ADS  objective  state- 
ments. The  objective  statements  will  be  such  that: 

a.  All  the  requirements  that  are  incumbent  on  the  ADS  from  any  source 
are  reflected  in  (i.e.,  accommodated  by,  or  mapped  into)  a set  of 
ADS  objectives,  which  itself  is  not  unnecessarily  extensive  (see 
Figure  5-01) . 

b.  The  objective  statements  exhibit  a high  degree  of  each  of  the 
intrinsic  serviceability  properties  desired  for  them. 
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TABLE  5-01.  SERVICEABILITY  PROPERTIES  OF  OBJECTIVE-CONSTRUCTS 
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A second  outcome  is  the  production  of  certain  aids  to  the  USMC  decision 
makers  who  must  ultimately  approve  the  ADS  objectives  as  part  of  the  ADS 
Development  Plan.  The  records  of  some  of  the  analyses  performed  during 
the  application  of  certain  of  the  procedures  can  be  furnished  to  the 
decision  makers  as  explanation  and  substantiation  of  the  appropriateness 
and  quality  of  the  objectives.  A third  outcome  is  the  revelation  of 
contradictions  or  other  inadequacies  in  the  requirements  in  response  to 
which  the  ADS  objectives  are  generated.  In  such  a case,  objective 
development  will  generally  be  terminated,  and  the  nature  of  the  diffi- 
culty will  be  made  known  to  those  responsible  for  formulating  and  vali- 
dating requirements. 

5.2.3  Inputs 

The  requirements-related  inputs  to  the  procedures  of  the  methodology 

are: 

a.  A body  of  stated  and  validated  user  requirements 

b.  A body  of  ADS  guidelines  and  constraints 

c.  A body  of  results  from  a Concept  Phase  Feasibility  Study 
(if  it  has  already  been  performed),  or  else  a hypothetical 
ADS  solution  approach  (if  objective-writing  is  being  con- 
ducted as  part  of  a Feasibility  Study). 

The  user  requirements  are  those  requirements--stated  from  the  user's 
viewpoint--that , if  satisfied,  would  solve  his  information  processing 
problem  or  need.  The  ADS  guidelines  and  constraints  represent  require- 
ments, both  directive  and  restrictive,  emanating  from  other  sources 
(such  as  higher  authority)  in  the  systems  development  environment.  The 
results  from  a concept  phase  feasibility  study,  or  alternatively,  the 
description  of  a hypothetical  ADS  solution  approach  being  considered  in 
a feasibility  study,  may  imply  requirements  on  the  form  or  characteristics 
of  the  ADS. 

The  user  requirements  are  contained  in  an  approved  Requirements 
Statement  (RS),  which  is  the  result  of  the  concept  phase  requirements 
development  activity.  The  ADS  guidelines  and  constraints  as  well  as  a 
description  of  a hypothetical  ADS  solution  approach  emanate  from  the 
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early  phases  of  the  feasibility  study  development  activity.  The  final 
results  are  embodied  in  an  approved  Feasibility  Study  (FS)  document. 
Figure  5-02  indicates  the  inputs  and  their  sources  for  the  two  slightly 
different  situations  in  which  objective -writing  can  be  applied. 

5.3  Objective  Writing  Techniques. 

5.3.1  Trial  Objective  Statements.  Trial  (or  provisional)  objective 
statements  are  a set  of  ADS  objective  statements,  developed  in  any  con- 
venient manner  and  in  any  state  of  refinement,  intended  for  use  in  the 
objective-writing  procedures  of  the  methodology.  They  are  postulated 
at  the  start  of  objective-writing  to  initiate  application  of  the  pro- 
cedures, and  they  are  successively  elaborated  and  refined  through  use 
of  the  procedures. 

The  trial  objective  statements  are  a body  of  well-defined,  mutually 
independent,  declarative  statements.  The  initial  set  of  trial  objective 
statements  is  used  in  the  first  application  of  an  objective-writing 
procedure.  Successively'  improved  versions  are  used  in  subsequent  appli- 
cations of  the  procedures. 

5.3.2  The  Requirements  Restatement  Procedure.  The  inputs  to  this  pro- 
cedure are  those  three  bodies  of  statements  identified  as  the  requirement 
related  inputs  to  the  procedures  of  the  objective-writing  methodology 
and  defined  in  paragraph  5.2.3.  The  purpose  of  this  procedure  is  the 
selective  restatement  of  statements  making  up  the  inputs,  without  alter- 
ing their  substance  and  meaning,  in  order  to  produce  one  comprehensive 
list  of  all  the  requirements  in  a simple  and  uniform  mode  of  expression. 

5. 3. 2,1  Procedure.  The  user  requirements  are  already  explicitly  stated 
as  requirements.  Simplicity  of  statement  is  a desired  feature.  If  some 
of  the  statements  are  composite  statements  that  incorporate  multiple 
requirements  into  one  expression,  then  these  should  be  split  into  multi- 
ple, simple  statements.  If  requirements  are  expressed  in  diverse  styles 
or  forms  of  expression,  then  they  should  be  transformed  into  parallel 
modes  of  expression. 


FIGURE  W>2  REQUIRED  INPUTS  FOR  OBJECTIVE-WRITING 
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The  ADS  guidelines  and  constraints  may  or  may  not  be  expressed  in 
forms  that  are  readily  recognizable  as  requirements.  All  requirements 
that  are  either  explicitly  or  implicitly  implied  by  the  guidelines  and 
constraints  should  be  made  visible.  Insofar  as  possible,  they  should 
be  expressed  in  the  same  form  as  the  user  requirements.  The  same  sim- 
plicity and  parallelism  of  the  statement  as  that  sought  for  the  user 
requirements  should  be  sought  here. 

To  the  extent  possible,  those  findings  and  decisions  of  the  Feasi- 
bility Study  that  imply  requirements,  or,  alternatively,  those  aspects 
of  an  alternative  ADS  approach  that  imply  requirements,  must  be  identi- 
fied and  expressed  explicitly  in  a form  comparable  to  that  of  the  other 
requirements . 

5.3.2. 1 Results.  The  resulting  list  of  uniformly  stated  requirements 
is  the  definitive  complete  list  of  requirement  statements  in  a form 
suited  for  input  to  the  requirements  mapping  procedure  described  in  the 
following  section. 

5.3.3  Requirements  Mapping  for  Completeness.  The  inputs  to  this  pro- 
cedure are  the  restated  requirements  defined  in  Section  5.2.2  and  the 
trial  objective  statements  defined  in  Section  5.2.1.  Mapping  is 
a technique  for  either  enhancing  or  verifying  the  intrinsic  property  of 
completeness  of  the  ADS  objectives.  If  the  trial  set  la  actually  com- 
plete, then  the  procedure  will  serve  to  demonstrate  '.ompleteness  with 
more  certainty  than  less  systematic  analysis  procedures.  If  the  trial 
set  is  not  complete,  then  the  procedure  can  expose  the  need  for  addi- 
tional objectives  that  must  be  adjoined  to  the  set  to  increase  complete- 
ness. 

5. 3.3.1  Procedure.  The  mapping  can  be  accomplished  by  the  actual  or 
figurative  use  of  the  matrix  shown  in  Figure  5-03.  Grouping  the  require- 
ments according  to  source,  in  the  manner  shown  along  the  top  of  the 
matrix,  is  merely  a convenience. 
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Proceeding  in  any  convenient  order,  one  works  through  all  possible 
combinations  of  individual  requirements  with  individual  objectives.  For 
each  requirement-objective  combination,  there  are  three  possibilities: 

a.  The  objective  contributes  in  some  way  to  the  satisfaction 
of  the  requirement. 

b.  The  objective  in  some  way  conflicts  with,  or  detracts  from, 
the  satisfaction  of  the  requirement. 

c.  The  objective  does  not  affect  the  satisfaction  of  the 
requirement. 

If  the  first  case  prevails,  one  enters  a "+"  in  the  corresponding 
matrix  cell.  If  the  second  case  prevails,  then  one  enters  a in  the 
cell.  If  the  third  case  prevails,  then  one  enters  a "0"  in  the  cell. 

In  many  instances  the  determination  of  the  cases  will  necessarily 
be  done  on  an  intuitive,  rather  than  a rigorous,  basis.  This  does  not 
preclude  useful  analyses  from  being  performed  from  the  results. 

After  having  traversed  the  entire  matrix,  one  makes  a variety  of 
analytical  checks.  Several  are  column-by-column  analyses.  First,  one 
looks  for  any  columns  consisting  entirely  of  zeros.  Such  a column 
reveals  a requirement  that  appears  not  to  be  addressed  by  any  of  the 
objectives  in  the  trial  set.  This  condition  argues  that  one  or  more 
additional  objectives  must  be  added  to  the  trial  set  to  increase  its 
completeness.  Furthermore,  a column  that  contains  a very  small  number 
of  pluses  among  zeros  may  (but  need  not  necessarily)  indicate  a require- 
ment that  is  only  partially  addressed  by  the  objectives.  This  matter 
should  be  Investigated. 

Second,  one  looks  for  columns  that  have  any  minuses.  The  presence 
of  a minus  ostensibly  indicates  that  an  objective  in  some  way  contra- 
venes the  requirement  in  question.  This  argues  that  the  objective  must 
either  be  modified  or  removed  from  the  set. 

An  additional  column-by-column  check  may  be  valuable.  A plus  in  a 
matrix  cell  only  signifies  that  the  objective  satisfies  the  requirement 
to  some  degree.  Hence,  even  the  presence  of  several  pluses  in  the  same 
column  does  not  ensure  that  the  requirement  will  be  fully  met.  There- 
fore, for  each  oolumn  (i.e.,  for  each  requirement)  the  question  can  be 
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asked:  "Do  the  objectives  indicated  by  the  pluses  ensure  that  the 

requirement  will  be  fully  met?"  If  the  answer  is  "yes,"  some  affirmative 
mark  should  be  placed  beneath  the  column.  If  the  answer  is  "no,"  then 
additional  objectives  would  seem  to  be  called  for. 

The  next  analysis  is  a row-by-row  analysis.  Here  one  looks  for 
any  row  that  has  no  pluses.  Such  a row  indicates  an  objective  that 
appears  to  address  none  of  the  requirements  and  hence  can  ostensibly  be 
eliminated  from  the  set.  Furthermore,  a row  that  contains  a very  small 
number  of  pluses  may  (but  need  not  necessarily)  indicate  an  objective 
that  is  not  particularly  effective  or  relevant  in  addressing  the  require- 
ments. Such  an  objective  is  a candidate  for  replacement.  Conversely, 
a row  with  many  pluses  may  tend  to  confirm  the  relevance  of  a particular 
objective. 

5. 3. 3.2  Results.  The  result  of  an  application  of  this  procedure  is  a 
new  set  of  trial  objective  statements  with  an  improved  degree  of  com- 
pleteness. This  set  can  be  submitted  to  other  procedures  for  other 
changes  and  refinements,  and  then,  if  it  is  useful,  resubmitted  to  this 
procedure  for  further  checking  and  refining  of  completeness. 

5.3.4  Pairwise  Checks  for  Consistency,  Independence,  and  Comparability. 
The  inputs  are  a set  of  trial  objective  statements.  This  pairwise  check- 
ing addresses  the  intrinsic  objective  properties  of  consistency,  inde- 
pendence, and  comparability.  The  procedure  provides  a systematic  and 
exhaustive  means  to  avoid  overlooking  conflicts,  overlaps,  and  discrepan- 
cies of  generality  in  the  objectives.  It  can  also  reveal  tradeoffs 
between  objectives. 

5.3.4. 1 Procedure.  One  successively  pairs  each  objective  with  every 
other  objective  in  the  set.  For  each  resulting  pair  of  objectives,  one 
poses  the  following  questions: 

a.  Regarding  consistency:  Are  the  two  objectives  in  any 

way  mutually  contradictory?  If  the  answer  is  "no,"  then 
no  action  is  taken.  If  "yes,"  then  there  are  two  possi- 
bilities to  be  considered.  The  first  is  that  the 
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contradiction  is  clearly  destructive,  and  it  should  be 
eliminated  by  modifying  one  or  both  of  the  objectives. 

The  second  possibility  is  that  the  contradiction  points 
to  the  existence  of  a tradeoff  between  system  character- 
istics implied  by  the  two  objectives  in  question.  The 
nature  and  acceptability  of  any  tradeoff  recognized  at 
this  point  should  be  analyzed  before  the  objectives  are 
either  modified  or  provisionally  accepted  without  modi- 
fication. Records  of  each  acceptable  tradeoff  identified 
by  this  means  should  be  maintained  for  subsequent  analysis. 

b.  Regarding  independence:  Do  the  two  objectives  redundantly 
address  or  imply  the  same  system  characteristic?  If  so, 
an  attempt  should  be  made  to  reformulate  one  or  both  of 
the  objectives  to  reduce  or  eliminate  the  redundancy, 

c.  Regarding  comparability:  Are  the  two  objective  statements 
expressed  in  terms  that  are  at  a similar  level  of  generality? 
If  the  answer  is  "no,"  there  is  not  necessarily  a clear 
cause  for  restatement.  Discrepancies  in  generality  may 
serve  only  to  prompt  a reanalysis  of  the  statements  to 
reveal  possible,  unintentional  lapses  In  level  of  detail, 
point  of  view,  or  terms  of  expression. 


S.3.4.2  Results.  The  result  is  a new  set  of  trial  objective  statements 
with  improved  degrees  of  consistency,  independence,  and  comparability. 
This  set  can  be  submitted  to  other  procedures,  and  then,  if  it  is  useful, 
resubmitted  to  this  procedure.  A second  result  consists  of  records  of 
tradeoffs  identified  in  the  consistency  analysis. 


5.3.5  Check  for  Simplicity.  The  inputs  to  this  procedure  are  the 
individual  objective  statements  of  a set  of  trial  objectives.  The  pur- 
pose of  this  procedure  is  to  enhance  the  intrinsic  property  of  simplicity 
by  splitting  objective  statements  that  express  composite  or  multiple 
objectives  into  separate  statements  that  express  simple  objectives. 

Often  it  is  one  of  the  first  checks  applied. 

5.3,5. I Procedure.  The  initial  check  for  simplicity  consists  of  a 
systematic  and  complete  reading  of  each  trial  objective  to  reveal  any 
obvious  opportunities  to  split  composite  objectives.  Each  such  oppor- 
tunity should  be  evaluated  and  acted  upon  accordingly. 
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The  second  step  in  the  procedure  entails  a tabulation  of  the  trial 
objectives  in  the  manner  indicated  by  Figure  5-04.  Each  objective  is 
analyzed,  and  its  implications  tabulated  in  the  following  four  categories. 

a.  Functional  implications.  These  are  strictly  concerned 
with  the  types  of  operations,  transformations,  or  com- 
putations a system  is  capable  of  executing. 

b.  Performance  implications.  These  are  concerned  with  the 
speeds,  rates,  or  capacities  of  system  functions  or 
activities. 

c.  Physical  design  implications.  These  are  concerned  with 
the  actual  physical  devices  or  physical  structure  of  the 
system. 

d.  System  quality  implications.  These  refer  to  complex  sys- 
tem aspects  such  as  security,  maintainability,  and  relia- 
bility, which  cannot  be  easily  expressed  in  terms  of 
functions,  performance,  and  structural  features. 

Each  objective  statement  will  have  an  entry  in  at  least  one  column 
of  the  figure.  However,  an  objective  may  have  entries  in  more  than  one. 
Such  objective  statements  may  embody  a composite  objective  and  can  be 
beneficially  separated  into  two  or  more  independent  statements. 


5. 3. 5. 2 Results.  The  result  of  this  procedure  is  a new  set  of  trial 
objectives  whose  individual  statements  exhibit  the  desired  degree  of 
simplicity. 

5.3.6  Determinability  Analysis.  The  inputs  to  this  procedure  are  the 
individual  objective  statements  of  a set  of  trial  objectives.  The  pur- 
pose of  this  procedure  is  to  discover  if  there  are  any  objectives,  which, 
because  of  the  way  they  are  stated,  permit  no  satisfactory  operational 
determination  of  objective  fulfillment. 


5.3.6. 1 Procedure.  Making  use  of  Figure  5-04,  one  analyzes  each  of  the 
implications  of  a given  objective  statement  in  turn,  and  asks  the  ques- 
tion: "Is  the  presence  or  absence  of  the  implied  system  characteristic 
capable  of  being  demonstrated  by  well-defined  operational  tests?" 
Objectives  stated  in  relative  terms  may  not  pass.  For  example,  the 


67 


I 


objective,  "The  ADS  must  provide  adequate  response  times  to  user  queries 
entered  from  a terminal,"  would  not  be  determinable  because  the  meaning 
of  "adequate"  is  not  well-defined.  This  objective  could  perhaps  be 
recast  in  terms  of  allowable  average  and  allowable  extreme  response 
times.  Similarly,  objectives  employing  the  term  "optimal"  would  be 
suspect  unless  well-def ined  criteria  for  optimality  were  to  exist. 

Satisfactory  objectives  must  at  some  point  in  the  development  cycle 
have  associated  with  them  usable  measures  of  objective  fulfillment, 
together  with  operational  procedures  for  evaluating  these  measures. 

For  those  objectives  that  are  deemed  determinable,  any  and  all  perceived 
measures  of  fulfillment  should  be  listed  together  with  their  associated 
determinability  tests.  The  points  in  the  development  cycle  at  which 
those  tests  can  be  performed  should  also  be  identified.  The  list  forms 
the  initial  nucleus  of  a test  plan  for  demonstrating  fulfillment  of  the 
objective. 

5. 3. 6. 2 Results.  The  result  of  this  analysis  is  a new  set  of  trial 
objectives  whose  individual  statements  exhibit  an  enhanced  degree  of 
determinability.  A second  result  is  the  production  of  the  nucleus  of 
a test  plan  for  demonstrating  objective  fulfillment. 

5.4  Objectives  after  the  Concept  Phase.  The  end  result  of  Concept 
Phase  objective-writing  is  a single  set  of  top-level  objectives  for 
the  ADS  as  a whole.  The  next  phase  of  system  development,  i.e.,  the 
Development  Phase,  must  necessarily  be  concerned  with  objectives  for 
individual  aspects  and/or  components  of  the  ADS.  This  gives  rise  to 
the  problem  of  deriving  more  detailed  or  lower-level  objectives  (often 
termed  specifications)  from  the  ADS  objectives.  This  activity  is 
referred  to  as  developing  a decomposition  of  objectives,  and  in  the 
terminology  of  this  report  it  consists  of  developing  a structure  of 

tlves.  Typically,  the  basis  for  developing  a decomposition  is  the 
..  i ret  i n >f  the  ADS  into  component  subsystems.  Subobjectives  are  then 
>r  e.tch  subsystem.  The  techniques  described  in  this  section 
..•I  '.r  .i  t > aid  considerably  in  this  decomposition  process  as  well. 
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SECTION  6.  ESTIMATING  ADS  LIFE  CYCLE  RESOURCES 


6.1  Requirement  for  LCC.  Discussions  of  cost  estimating  for  DoD 
related  systems  can  usually  be  taken  as  a requirement  to  provide  Life 
Cycle  Cost  (LCC)  estimates  under  DoD  Inst  7041.3.  There  have  been  many 
attempts  to  extend  the  Life  Cycle  analysis  with  its  terms  and  definitions 
to  ADS  as  well.  These  terms,  which  are  generally  understood  in  hard- 
ware related  systems,  do  not  lend  themselves  well  for  use  in  describing 
the  ADS  life  cycle.  With  almost  every  study  of  ADS  Life  Cycle  Cost 
come  new  suggestions  for  a general  ADS  terminology;  however,  these 
efforts  for  a general  terminology  have  not  yet  been  successful.  With- 
out such  a standard,  it  becomes  necessary  to  define  for  this  study  the 
life  cycle  phases  and  their  corresponding  Life  Cycle  Cost  elements. 

Table  6-01  shows  how  ADS  terms  used  in  this  section  relate  to  LCC 
requirements  specified  for  military  systems  in  general. 


Table  6-01 

LIFE  CYCLE  PHASES  FOR  ADS  AND  OTHER  DOD  SYSTEMS 


ADS  Life  Cycle  Phases 

TRI-TAC* 

ADSM  Ch.  14 

Concept  phase 

R&D 

Development  phase 

Nonrecurring  investment 

R&D 

System  implementation 

Recurring  investment 

Investment 

System  operations 

Annual  operating 

Recurring  operations 

*The  TRI-TAC  Life  Cycle  Cost  Study  has  been  accepted  by  the  research 
community  as  a standard  for  LCC  analysis. 


Of  the  Life  Cycle  Costs  that  must  be  estimated,  those  required  to 
develop  the  ADS  software,  i.e.,  the  man-hour  expenditure  for  analysis, 
programming,  and  testing  are  by  far  the  most  important  and  difficult  to 
forecast.  This,  too,  has  been  subject  to  considerable  study  over  the 
past  fifteen  years,  but,  as  with  classifying  LCC  elements,  generally 
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accepted  estimating  standards  have  not  been  established.  A cursory 
review  of  the  literature  indicates  that  there  are  two  basic  categories 
of  ADS  resource  estimating.  Micro,  meaning  that  the  estimate  is  the 
sum  of  individually  described  activities  at  a relatively  fine  grain 
level;  and  Macro,  meaning  that  some  overall  or  gross  order  of  magnitude 
estimating  methodology  is  used.  Macro  approaches  are  used  usually  when 
the  system  detail  description,  such  as  that  used  in  the  micro  approach, 
is  completely  beyond  reason. 

The  micro/macro  classification  is  now  generally  acknowledged. 

DoD  sponsored  a joint  study  group  that  was  formed  in  March  1975  to 
establish  a DoD  ADS  resource  estimating  methodology.*  The  resulting 
recommendations  have  yet  to  be  formalized  and  put  into  DoD  instructions; 
however,  interim  findings  are  that  DoD  should  adopt  a method  similar 
to  what  is  termed  the  Fort  Lee  method  for  microestimating,  and  a model 
being  developed  by  L.  H.  Putnam,  Col.,  USA,  as  a macroestimating 
methodology.  It  is  important,  therefore,  that  any  study  of  this  subject 
for  USMC  use  consider  seriously  the  relative  merits  of  these  two 
methodologies . 

Both  micro-  and  macroestimating  approaches,  and  several  techniques 
within  each,  were  studied  and  reported  on  in  the  May  1977  Technical 
Note  on  the  topic.  The  approaches  recommended  as  result  of  the  study 
are : 

a.  Macro — Direct  analogy  and  Delphi  techniques  in  either  of 

several  variations. 

b.  Micro — The  methodology  developed  by  SRI  for  USMC  use. 

The  recommendations  contained  in  the  present  report  reflect  the  result 
of  further  investigations  into  the  subject  brought  on  by  the  review 
process  of  the  May  Technical  Note,  as  well  as  developments  within  the 
DoD  ADS  community  since  the  TN’s  publication. 


*This  group  was  sponsored  by  OASD(C)  in  a January  75  memo  establishing 
New  Automation  Objectives  for  the  Department  of  Defense.  The  specific 
study  group  referred  to  here  was  formed  to  satisfy  Objective  3A,  which 
was  to  develop  a DOD  Baseline  Resource  Estimating  Model  (DBREM) . 
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6.2  ADS  Life  Cycle  Cost  (LCC)  Elements.  This  section  defines  and 
discusses  ADS  Life  Cycle  Cost  and  Resource  elements  referred  to  In  the 
proposed  methodology.  These  elements  are  designed  to  highlight  the  ADS 
life  cycle  process,  and  present  a procedure  or  methodology  whereby 
Marine  Corps  analysts  can  make  timely  estimates  of  ADS  Life  Cycle  Costs 
(particularly  ADS  development  costs)  to  support  the  feasibility  Study 
and  Economic  Analysis  requirements. 

6.2.1  LCC  Cost  Elements.  Table  6-02  shows  the  ADS  life  cycle  as 
consisting  of  four  phases: 

a.  Concept  Formulation  Phase 

b.  Development  Phase 

c.  System  Implementation  Phase 

d.  System  Operation  and  Maintenance  Phase. 

Within  each  phase  are  distinct  and  separable  activities,  which  can  be 
. grouped  to  form  an  ADS  LCC  element.  Table  6.02  lists  the  major  (cost 

breakdown)  elements  and  associated  activities  for  these  elements.  It 
is  important  to  note  that  the  elements  refer  to  activities  or  events 
and  not  resources,  such  as  manpower  or  items  of  expense.  This  separation 
serves  several  purposes.  First,  it  clearly  distinguishes  between  tasks 
to  be  performed  and  resources  required.  Second,  it  allows  elements  and 
resources  to  be  cross-indexed  to  form  a cost-resource  matrix.  Ready 
access  to  cost  information  by  cost  category  and  resource  type  is  one  of 
the  primary  benefits  of  presenting  costs  in  matrix  form. 
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Table  6-02 


ADS  LCC  COST  ELEMENTS  AND  RELATED  ACTIVITIES 


LCC  Cost 
Element 

1 Concept  Formulation^ 

1.1  User  Requirements  Development 

Statement  of  user  requirements 
User  requirement  validation 

Preliminary  suggestion  of  alternative  concepts 

1.2  Feasibility  Study 

Formulation  of  objectives 
Development  of  alternative  approaches 
Technical  Feasibility  analysis 
Operational  Feasibility  analysis 
Economic  Feasibility  analysis 
Select  preferred  approach(es) 

Feasibility  Study  (FS)  document  preparation 

1.3  ADS  Development  Plan 

Functional  Description  (FD)  document  preparation 

DAta  Requirements  (RD)  document  preparation 

ADP  Equipment  Specifications  (ADPES)  document  preparation 

Economic  Analysis  document  preparation 

ADS  Development  Plan  (ADSDP)  document  preparation 

2 ADS  Development^- 

2.1  Analysis  and  Design 

System  configuration/architecture  analysis 
System  flow  design 
Files  design 

Program  specifications  writing 
System  test  plan  development 

System  implementation/training  plan  development 

2.2  Programming  (Coding) 

Module  coding 
Module  debugging2 
Module  testing 

2.3  Test  and  Evaluation 

Integration  and  system  debugging 
Testing  with  test  data 
Parallel  operation  and  evaluation 
Completion  of  documentation 


^Resources  used  are  primarily  manpower  and  computer  processing  costs. 
2 

Debugging  is  the  process  of  getting  the  module  to  function — i.e.,  to 
"run";  testing  is  the  process  of  determining  if  the  working  module 
performs  the  desired  function(s). 
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Table  6-02  (Concluded) 

LCC  Cost 

Element  (Continued) 

2.4  ADS  Project  Management  Plan 

Monitoring  and  evaluation  of  ADS  development  activity 

3 System  Implementation 

3.1  ADS  Hardware/Software  Acquisition 

•Source  selection  and  contract  negotiations 
Procurement,  transportation,  and  shipping  costs 
Receiving,  checkout  and  inspection  charges 

3.2  Initial  Training 

Instructor  costs  (MPA,  transportation,  per  diem) 

Student  costs  (MPA,  transportation,  per  diem) 

Training  equipment  and  facility  costs 

Computer  processing 

Contracted  services  (for  training) 

3.3  User  Manuals  and  System  Documentation 

User  manual  preparation 
Printing  and  distribution  costs 

3.4  Site  Activation 

Facility  planning,  modification  and  moving  expenses 
Initial  start-up  costs,  including  assembly  and  installation 
Furnishings 

Rents,  utilities,  and  communications 

3.5  Initial  Provisioning 

Spares  and  spare  parts 
Supplies  and  materials 

Maintenance  equipment,  tools  and  instruments 

3.6  ADS  Project  Management 

System  implementation  planning,  scheduling,  monitoring 
and  evaluation 

4 ADS  System  Operation 

4.1  System  Operations 

Operator  personnel  costs 
Computer  processing  costs 
Supplies  and  services 
Operator  replacement  and  training 

4.2  Equipment  and  Facility  Maintenance 

Maintenance  personnel  costs 

Computer  hardware  and  software  service  contracts 
Utilities,  rents,  and  communications 
Facility  maintenance  costs 

4.3  ADS  System  Charges  and  Modifications 

Personnel  costs  for  system/program  changes  and  modifications 
Computer  processing  costs  for  system  maintenance 

4.4  ADS  Project  Management 

Project  office  costs 
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6.2.2  ADS  Resources.  The  resources  discussed  in  the  following  two 
sections  of  this  report  concern  personnel  and  development  time  only. 
Further,  they  treat  only  those  resource  costs  that  can  be  translated 
into  dollars.  Opportunity  costs*  are  specifically  addressed  in 
Volume  II  of  this  report  and  are  not  added  to  the  cost  of  a proposed 
ADS. 

ADS  resources  described  in  Chapter  14,  Appendix  C of  the  ADSM  as 
"Elements  of  Expense"  may  be  useful  for  estimating  the  costs  of  ADS 
implementation  (Section  4.5)  and  ADS  operations  and  support  (Section  4.6), 
but  should  not  be  used  for  estimating  the  cost  of  personnel.  Personnel 
costs  need  to  be  based  on  total  costs  to  the  government  for  a given 
cause  of  action.  Using  budgetary  or  personnel  salary  costs  understates 
their  actual  cost  and  thereby  favors  alternatives  having  higher  per- 
sonnel costs,  other  things  being  equal.  A more  appropriate  cost  for 
personnel  is  noted  in  Appendix  B as  "Billet  Costs."  These  costs  have 
been  developed  for  use  in  Navy  Life  Cycle  Cost  studies  by  NAVPERS. 

6.3  Estimating  ADS  Development  Costs.  Choosing  which  of  the  basic 
approaches  to  use  for  estimating  ADS  development  costs  is,  of  course, 
the  initial  step  in  the  estimating  process.  However,  selection  of  one 
approach  over  the  other  does  not  preclude  the  possibility  that  both 
may  be  used  to  some  extent  before  the  final  estimate  is  made.  Typically, 
however,  this  question  is  a moot  point  for  the  availability  of  data 
needed  to  form  an  estimate  and  the  overall  size  of  the  project  deter- 
mines which  approach  is  to  be  used.  It  is  virtually  impossible  to  employ 
microestimating  techniques  on  very  large  and  vaguely  defined  program- 
ming tasks;  conversely,  to  use  a Delphi  estimate  for  a very  definitive 
task  requiring  on  the  order  of  a couple  of  man-months  to  accomplish  is 
unlikely  to  produce  as  accurate  an  estimate  as  could  be  developed  by 
the  right  analyst  using  microestimating  techniques.  In  general,  projects 


*The  costs  of  having  to  reassign  personnel  or  equipment  between  projects, 
thereby  delaying  benefits  which  would  accrue  from  alternative  assign- 
ments. 
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ranging  from  two  man-weeks  to  six  man-years  are  likely  candidates  for 
microestimating  techniques.  Larger  systems  requiring  two  to  twenty 
man-years  of  development  effort  are  usually  better  suited  for  macro 
approaches,  either  Direct  Analogy  or  Delphi  approaches. 

The  following  two  sections  present  a recommended  methodology  for 
both  macro-  and  microestimating  techniques.  However,  the  analyst  is 
responsible  for  his  estimate  and  will  therefore  use  any  means  available 
to  arrive  at  estimates  he  believes  he  can  defend.  These  procedures  are 
offered  to  provide  a benchmark  methodology  for  USMC  use  where  estimating 
performance  can  be  evaluated  over  time. 

6.3.1  Macroestimating  ADS  Development  Time.  Two  macroestimating  tech- 
niques are  recommended — the  Direct  Analogy  and  Delphi  techniques. 

6. 3. 1.1  Direct  Analogy.  In  Direct  Analogy  approaches,  the  proposed 
ADS  is  compared  with  one  or  more  previous  ADS  developments  of  similar 
characteristics.  The  procedure  requires  that  the  proposed  project  be 
subdivided  into  tasks  that  correspond  to  those  for  the  project  being 
used  as  a comparison  base.  That  highlights  areas  where  there  is  good 
comparability,  and  therefore  a more  certain  basis  for  an  estimate. 

It  also  minimizes  the  high  risk  that  results  from  having  little  or  no 
prior  experience.  This  approach  is  predicated  on  having  a historical 
data  base  upon  which  to  draw.  These  data  have  not  been  well-maintained 
at  HQMC  in  the  past,  with  the  corresponding  consequence  that  Direct 
Analogy  approaches  to  resource  estimating  are  severely  encumbered, 
although  not  precluded.  Even  such  gross  data  as  development  time  and 
project  manning  provide  valuable  aids  for  the  macroestimator. 

6. 3. 1.2  Delphi  Approaches.  Delphi  techniques  were  developed  by  Dalkey 
and  Helmer  of  the  Rand  Corporation  in  the  early  1960s,  as  a systematic 
procedure  to  refine  expert  judgment.  They  are  commonly  employed  for 
the  very  subjective  problems  about  which  there  is  uncertainty  and  often 
controversy.  There  are  a number  of  variants,  but  basically  the  Delphi 
method  consists  of  the  following  steps:  (1)  structuring  objective  ques- 
tions, (2)  soliciting  independent  responses  from  a panel  of  expert 
witnesses,  (3)  feeding  back  the  distribution  of  responses  to  the  partici- 
pants (with  rationale),  (4)  obtaining  a second  response,  and  (5)  exploring 
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the  basis  for  those  responses  farthest  from  the  mean,  and  repeating 
steps  (3)  and  (4)  several  times  to  reach  a consensus. 

The  Delphi  procedure  works  well  in  many  situations,  particularly 
those  in  which  the  experts  are  drawn  from  a number  of  independent  per- 
spectives. When  it  fails,  the  failure  is  usually  caused  by  an  incestuous 
opinion  concentration,  or  because  some  unforeseen  event  or  problem 
developed  that  was  out  of  the  realm  of  the  experience  base  of  the  experts 
paneled . 


The  Delphi  method  is  recommended  subject  to  the  following  conditions. 
First,  the  Delphi  method  must  be  feasible  from  a cost  and  time  point  of 
view.  It  is  an  inherently  expensive  process,  requiring  considerable 
man-hour  involvement  over  a relatively  lengthy  time.  Second,  the  panel 
of  experts  must  represent  independent  perspectives,  but  at  the  same  time 
they  should  have  some  basis  for  making  their  estimates.  In  this  con- 
text, experts  should  be  drawn  from  staffs  of  the  three  CDPAs,  Functional 
Managers  staff,  and — if  possible — representatives  from  commercial  soft- 
ware development  firms  and  previous  CJSMC  programmers  and/or  consultants. 


The  procedure  for  setting  up  a Delphi  approach  should  approximate 
the  following: 

Step  0.  Identify  a panel  of  experts  who  have  agreed  to  participate. 

Step  1.  Prepare  a description  of  project  objectives,  proposed 
approaches,  etc. 

Step  2.  Determine  the  objective  questions. 

The  requirement  here  is  to  develop  at  least  one,  but 
preferably  several,  questions  that  address  the  primary 
size  problem  in  straightforward  terms.  For  example,  a 
series  of  questions  might  be: 

Q.l.  What  is  your  estimation  of  the  development  time  (calendar 
time  from  project  go-ahead  to  the  first  full  production 
run? 

Q.2.  What  is  your  estimate  of  the  maximum  programmer-analyst 
manning  level? * 


*These  questions  are  primary  inputs  to  the  DoD  preferred  "Putnam"  macro- 
estimating model,  and  as  such,  may  be  used  to  develop  an  alternative 
estimate  when  the  DoD  instruction  on  ADS  cost  estimating  is  promulgated. 
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Q.3.  Referring  to  Q.2 , what  is  your  estimate  of  time  before 
that  manning  level  is  reached?* 

Q.4.  What  is  your  estimate  of  steady-state  maintenance  of  the 

system  once  it  has  been  debugged,  documented,  and  fielded? 

Step  3.  Solicit  confidential  responses  from  the  panel  of  experts, 
giving  them  a brief  description  of  the  Delphi  approach 
and  informing  them  of  what  will  be  expected.  The  requests 
should  also  include  the  following  instructions: 

(a)  For  your  estimate  to  be  valid,  it  must  be  made  inde- 
pendently of  other  participants.  You  may  consult 
other  associates  and  any  information  sources  normally 
available  to  you  in  forming  your  response. 

(b)  If  you  feel  your  judgment  is  without  basis  or  under- 
standing, you  may  reword  the  question,  or  refuse  to 
answer  it;  however,  indicate  the  rationale  or 
problem  you  encountered  when  attempting  to  form  your 
response.  Your  remarks  should  be  helpful  to  other 
participants  in  later  rounds,  rather  than  a ration- 
alization for  not  answering  the  question. 

(c)  Please  indicate  any  answer  that  you  believe  should 
be  more  heavily  weighted  because  of  your  high  degree 
of  confidence  in  that  response  (for  example,  you 
may  find  you  hold  knowledge  that  other  participants 
lack  and  therefore  your  response  has  higher  credi- 
bility) . 

Step  4.  Evaluate  round-one  responses  and  prepare  the  statistical 
distributions  of  responses  for  the  participants  to  use  in 
round  two.  This  feedback  should  include  graphic  represen- 
tation of  range,  clustering,  and  should  note  the  rationale 
given  for  the  responses  that  deviate  significantly  from  the 
central  cluster.  The  purpose  of  subsequent  response 
solicitation  is  to  inform  the  participants  of  the  results 
of  the  previous  round  and  allow  them  the  opportunity  to 
revise  their  responses  in  light  of  the  new  data. 

Step  5-8.  These  essentially  repeat  Steps  3 and  4 for  those  ques- 
tions for  which  a consensus  has  not  been  established.  It 
is  normally  not  necessary  to  repeat  questions  on  which 
there  is  agreement. 

Upon  completion  of  the  Delphi  process,  estimates  will  have  been 
generated,  based  on  the  intuition  or  "opinion"  of  an  expert  panel.  It 
is  important  to  remember  that  these  estimates  are  simply  the  collective 


*These  questions  are  primary  inputs  to  the  DoD  preferred  "Putnam"  macro- 
estimating model,  and  as  such,  may  be  used  to  develop  an  alternative 
estimate  when  the  DoD  instruction  on  ADS  cost  estimating  is  promulgated. 
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opinion,  and,  while  they  presumably  benefit  from  the  body  of  all  avail- 
able knowledge,  they  are  just  as  prone  to  error  as  those  produced  by 
other  means. 


6.3.2  Microestimating  ADS  Development  Time.  There  are  two  microestimat- 
ing techniques  that  may  be  appropriate  for  USMC  use.  One  is  called  the 
"Fort  Lee  Method."  Developed  for  the  U.S.  Army,  it  is  described  in 
detail  in  USACSCSGL  Memo  18-1  of  16  December  1976,  entitled,  "SCR  Esti- 
mating Procedures."  The  other,  proposed  by  SRI  International,  is 
presented  in  detail  in  the  succeeding  section.  The  two  methods  have  a 
slightly  different  orientation.  The  Fort  Lee  Method  appears  to  be 
designed  to  estimate  resources  required  for  modification  efforts  or 
developmental  efforts  that  are  well  into  the  design  phase.  The  SRI 
method  requires  less  specific  inputs  and  may,  therefore,  be  used  more 
effectively  in  the  Concept  phase.  In  this  sense,  the  two  models  are 
complementary.  Under  sample  conditions,  both  produce  similar  estimates. 
If  the  DoD  adopts  the  Fort  Lee  Method  as  its  standard  microestimating 
procedure,  the  USMC  should  consider  using  the  SRI-proposed  method  during 
concept  development  and  the  Fort  Lee  Method  later  in  the  process  (i.e., 
after  the  design  detail  is  available). 

The  SRI  methodology  presented  here  is  a bottom-up  technique, 
based  primarily  upon  parametric  estimating  relationships.  For  purposes 
of  resource  estimation,  the  ADS  development  phase  has  been  divided  into 
the  following  phases: 

a.  Analysis  and  Design 

b.  Programing 

c.  Test  and  Evaluation 

d.  Documentation* 

An  estimating  relationship  is  formulated  for  each  phase;  as  a whole, 
they  produce  a general  model  for  estimating  total  ADS  development  time 
(in  man-days): 


*While  documentation  is  actually  a task  within  the  other  phases,  it  is 
treated  as  a phase  for  purposes  of  estimation. 


DEVELOPMENT  TIME  = A&D  + ^J-ROGRAMMING  + T&E  + DOCUMENTATION  (6-1) 


Note  that  all  phases  have  single-value  estimates,  except  the  programming 
phase,  which  is  a summation  over  estimates  of  the  individual  programs. 
Factors  influencing  development  time  that  affect  all  phases  are  then 
applied. 

This  methodology  was  designed  to  produce  estimates  for  efforts  that 
require  from  approximately  two  man-weeks  to  six  man-years — the  size 
range  for  which  bottom-up  techniques  have  been  applied  with  some  confi- 
dence. The  Methodology  is  easily  adapted  to  either  full-scale  develop- 
ment efforts  or  system  modification,  and  maintenance  tasks. 

6.3. 2.1  Analysis  and  Design.  A&D  man-days  are  estimated  for  the  entire 
project.  Estimating  factors  are  system  complexity,  general  A&D  experi- 
ence, and  functional  knowledge  of  the  specific  job  to  be  automated  or 
modified.  While  system  complexity  is  directly  proportional  to  the 
amount  of  manpower  expended,  the  other  two  factors  are  inversely  pro- 
portional. They  may  be  expressed  mathematically  as  follows: 

A&D  MAN-DAYS  = [ SYSTEM  COMPLEXITY 

FOR  PROJECT  | A&D  EXPERIENCE  + JOB  KNOWLEDGE 

The  weighting  scales  for  this  relationship  are  ound  in  Appendix  B, 

Table  B-01.  Supporting  rationale  and  a description  of  how  these  scales 
were  derived  and  how  they  may  be  modified  are  found  in  Appendix  B, 
Section  1.0.  The  weighting  scales  are  designed  for  a full  range  of 
estimates — i.e.,  from  minor  modification  to  complete  development  of  a 
major  system. 

6. 3. 2. 2 Programming.  The  estimating  relationship  for  the  programming 
effort  is  logically  identical  to  that  for  A&D.  The  fundamental  dif- 
ference is  that  programming  estimates  must  be  produced  individually  for 
each  programming  module  to  account  for  the  varying  module  complexities 
and  varying  programmer  skill  levels.  In  addition,  a shop's  productivity 
is  greatly  influenced  during  the  programming  and  T&E  phases  by  system 
turnaround  for  submitted  work.  The  extremes  for  turnaround  range  from 


(6-2) 
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having  interactive  access  via  a terminal  in  the  programmer ' s office, 
to  courier  pickup  and  delivery  of  low-priority  card  decks  when  the 
programmer  and  computer  are  in  separate  locations.  Because  the  situation 
may  be  different  for  the  programming  and  T&E  phases,  the  factors  should 
be  applied  separately  to  those  two  phases.  The  turnaround  categories 
are  defined  for  the  Methodology  with  the  appropriate  quantitative  values 
in  Appendix  B,  Table  B-02. 

Summing  over  the  modules,  the  total  programming  effort  may  be 
expressed  thus: 


PROGRAMMING 
MAN-DAYS  = 
FOR  PROJECT 


IS*®-, 


(PROGRAM  COMPLEXITY) j 


(EXPERIENCE  + JOB 


KNOWLEDGE)) 


/TURNAROUND 
\ FACTOR 

(6-3) 


6. 3. 2. 3 Test  and  Evaluation.  The  T&E  phase  is  the  most  difficult  of 
the  three  development  phases  to  estimate.  While  the  A&D  phase  produces 
a specific  plan  for  T&E,  T&E  is  nonetheless  the  phase  in  which  the  un- 


anticipated appears.  Problems  overlooked  during  A&D,  and  which  remain 


hidden  during  the  coding,  may  appear  for  the  first  time  during  testing. 
It  is  the  resource  impact  of  those  unknowns  that  must  be  accounted  for. 


Intuitively,  one  would  imagine  that  the  better  the  A&D  work,  the 
less  time  the  T&E  will  require.  However,  looking  over  ADS  histories 
available  in  the  literature,  one  finds  that  the  ratio  of  effort  spent 
on  the  T&E  phase  is  roughly  proportional  to  that  spent  on  the  A&D 
portion  (one  to  one).  This  leads  to  the  conclusion  that  both  efforts — 
over  the  long  run — are  based  largely  on  system  complexity.  As  a result, 
the  proposed  T&E  estimating  relationship  is  similar  to  that  for  A&D. 

This  helps  the  estimator  know  what  "ballpark"  his  estimate  should  be 
in,  and  is  useful  during  actual  development  for  estimate  modification 
if  the  A&D  effort  is  proceeding  faster  or  slower  than  expected. 


The  basis  of  the  T&E  estimating  relationship  is  identical  to  that 
for  A&D,  with  the  exception  that  programmer  and  analyst  talent  is  aver- 
aged since  both  types  participate  in  the  T&E  effort.  The  A&D  weighting 
scales  should  be  used.  The  uncertainties  mentioned  earlier  can  be 
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treated  with  an  equalizing  factor  that  takes  into  account  lower-  or 
higher-than-average  T&E  activities.  By  computing  the  mean  of  these  dis- 
crepancies, we  have  such  an  equalizing  factor.  It  is  called  the  Mean 
T&E  Requirement  (MTER)  and  is  computed  by  summing  the  T&E  requirements/ 
component,  as  determined  in  Appendix  B,  Table  B-03,  and  dividing  by  five. 

The  T&E  relationship  is  thus  expressed  as  follows: 

T&E  MAN-DAYS  _ [/ SYSTEM  COMPLEXITY 

FOR  PROJECT  ' M ANALYST -PROGRAMMER  (EXPERIENCE  + JOB  KNOWLEDGE) 

/ TURNAROUND \1 
* <KTE>»  * ( FACTOR  )| 

6. 3. 2. 4 Documentation.  The  cost  of  documentation  is  often  estimated 
as  a last  phase  (after  T&E)  in  the  development  effort.  While  a portion 
of  this  activity  must  be  handled  after  the  system  is  fully  tested — e.g., 
final  writing  and  reproduction — the  effort  continues  through  all  stages 
of  development.  It  is,  in  fact,  highly  integrated  into  other  activities. 
For  example,  the  system  designer  will  produce  program  specifications  for 
the  programmer's  use;  these  working  documents  form  the  substance  of  the 
Functional  Description.  Because  of  such  integration,  it  may  be  deduced 
that  the  documentation  effort  is  proportional  to  the  complexity  of  the 
system,  and  therefore  requires  a proportional  level  of  effort  across 
the  entire  development.  For  the  same  reason,  this  task  will  tend  to 
be  fairly  constant  over  the  majority  of  developments,  and  it  is  recom- 
mended that  this  overall  effort  be  assessed  at  5%  of  the  net  total 
development  time.  For  atypical  documentation  requirements,  this  number 
may  be  modified  up  or  down  as  appropriate.  The  documentation  effort 
may  therefore  be  estimated  by  the  following  relationship: 

DOCUMENTATION  MAN-HOURS  FOR  PROJECT  = (TOTAL  PROJECT  MAN-HOURS)  x ,05  (6-5) 

The  methodology  presented  thus  far  has  been  explained  in  terms  of 
full-scale  development.  It  is  easily  applied  to  software  modification 
efforts  by  the  same  principles.  For  example,  suppose  one  program  in  a 
large  system  has  to  be  changed.  For  the  A&D  activities,  most  of  the 
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applicable  weighting  factors  would  be  in  the  0-3  range.  The  programming 
weighting  factors  are  also  reduced,  depending  on  how  much  code  is  still 
usable.  The  T&E  phase  is  reduced  corresponding  to  the  reduction  in  the 
A&D  effort  and  can  be  modified  further.  Modification  is  no  harder  to 
estimate  than  development  when  one  can  adjust  the  complexity  to  reflect 
the  effort  affected  by  previous  programming.  In  other  words,  original 
complexity,  minus  the  reduction  in  complexity  brought  about  by  earlier 
programming,  yields  the  remaining  complexity. 

6. 3. 2. 5 Productivity  Degradation  Factor.  The  sum  of  the  estimates  for 
the  A&D,  Programming,  and  T&E  phases  yields  a nominal  (productive) 
development  time.  That  is,  this  estimate  is  exclusive  of  normal  and 
unexpected  downtime  and  assumes  a constant,  optimum  level  of  productivity 
throughout  development.  Real  world  obstacles  to  optimum  productivity 
are  abundant  and  must  be  taken  into  consideration.  Collectively,  these 
are  referred  to  as  the  Productivity  Degradation  Factor.  Although  the 
components  of  this  factor  are  common  to  all  data  processing  installations, 
the  actual  value  of  the  Production  Degradation  Factor  may  vary  from  site 
to  site.  As  a baseline  figure,  it  is  recommended  that  a value  of  1.6 
be  multiplied  by  the  nominal  development  time  to  yield  actual  manpower 
requirements. 

It  should  be  noted  that  productivity  is  also  degraded  according  to 
the  manning  level  of  a project.  This  results  from  problems  of  coordina- 
tion that  develop  among  larger  groups  of  people  and  the  increasing  need 
to  devote  time  to  strictly  managerial  or  administrative  activities.  In 
the  microestimating  realm,  this  problem  is  relatively  negligible 
because  the  manning  levels  of  projects  of  several  man-years  or  less 
never  truly  increase  beyond  the  "surgical  team"  dimensions.  For  this 


reason,  it  is  probable  that  the  Productivity  Degradation  Factor  can 
remain  constant  at  any  given  site.  This  factor  is  the  appropriate 


6.3.3  Proposed  Estimating  Equation.  The  component  estimating  relation- 
ships have  now  been  defined.  In  combining  them,  the  total  manpower 
estimating  equation  may  be  specified  as  follows: 


SYSTEM  COMPLEXITY 


A A D EXPERIENCE  + JOB  KNOWLEDGE 


\t( 


(PROGRAM  COMPLEXITY): 


PROGRAMMER:  (EXPERIENCE  + JOB  KNOWLEDGE) 


^turnaround|  + 


SYSTEM  COMPLEXITY 


\ FACTOR 


ANALYST-PROGRAMMER  (EXPERIENCE  + JOB  KNOWLEDGE)^ 

\ll 


X rMTFRi  X /turnaround^/  x /documentation^  /productivity \ 

(MTLRI  ^ F4Cro,  )jj  * \ FACTOR  105  ) y FACT0R  , e / 
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Table  B-04  in  Appendix  B is  a sample  estimating  worksheet  provided  to 
assist  the  user  in  preparing  estimates  of  ADS  development  using  this 
methodology.  Again  the  weighting  scales  to  be  used  in  quantifying  the 
estimating  factors  are  itemized  in  Appendix  B. 

6.3.4  Costs.  The  primary  development  cost  is  the  cost  of  personnel 
assigned  to  the  development  process.  For  this  reason,  the  previous 
sections  have  dealt  totally  with  estimating  project  man-year  expenditures. 
The  use  of  computer  processing  time  during  development  is  not  usually 

a significant  factor,  but  it  may  become  one.  This  cost  has  been  treated 
in  the  methodology  as  an  overhead  cost  applied  to  the  cost  of  a programmer- 
analyst.  This  assumption  should  be  examined  when  making  an  estimate  to 
be  sure  the  cost  is  adequately  covered.  Appendix  B Tables  B-05  and  B-06 
show  the  cost/man-year  in  1977  dollars  for  different  rank  and  skill 
levels.  The  factors  include  payroll  burden  and  overhead  charges  in 
addition  to  base  pay  and  allowances.  Section  6 discusses  the  applica- 
tions of  escalation  factors  to  be  used  as  multipliers  for  the  man-year 
expenditure  for  the  year  in  which  it  is  incurred. 

6.4  Estimating  ADS  Implementation  Costs.  Analysis  of  historical  data 
supports  using  a 1:3  ratio  of  ADS  implementation  to  ADS  development. 
However,  one  must  use  this  relationship  with  caution  for  any  ADS  system 
implementation  costs  may  vary  over  an  extremely  wide  range.  Because  an 


ADS  may  or  may  not  involve  hardware  acquisition  or  require  off-site 
processing,  there  is  virtually  no  direct  correlation  between  development 
and  implementation.  Except  for  those  ADS  that  involve  extensive  hard- 
ware costs,  the  major  implementation  cost  is  that  for  the  personnel 
required  to  transport  the  software  to  the  required  sites,  train  operators 
and  users,  and  monitor  an  initial  period  of  operation.  Since  ADS  develop- 
ment personnel  often  assume  responsibility  for  system  implementation,  it 
may  be  useful  to  estimate  implementation  cost  as  a function  of  develop- 
ment costs.  The  macroestimating  approach  described  and  summarized  in 
Section  3 of  the  SRI  Technical  Note  NWRCTN-72  of  May  1977  allows  the 
following  relationship: 

System  implementation  = (.285)  (ADS  development  costs) 

= (.105)  (Total  ADS  life  cycle  costs)* 

If  the  ADS  involves  hardware  and  site  activation  (i.e.,  more  than  simply 
a software  package),  and,  for  those  larger  ADS  developments,  system 
implementation,  estimating  its  cost  is  an  entirely  different  matter. 

The  Resource  Estimating  Methodology  is  understandably  different 
for  the  above  two  situations.  The  topics  discussed  below  address  the 
more  involved  system  implementation  case.  When  applying  this  Methodology 
the  user  may  find  that  some  of  the  items  below  can  be  skipped  as  "not 
applicable." 

System  implementation  is  broken  down  into  the  following  categories:^ 

a.  ADS  Hardware/Software  Acquisition 

b.  Initial  Training 

c.  User  Manuals  and  System  Documentation 

d.  Site  Activation 

e.  Initial  Provisioning 

f.  ADS  Project  Management. 

6.^.1  ADS  Hardware/Software  Acquisition.  Estimating  hardware  costs  can 
prove  a paradoxical  task.  Although  current  prices  are  easily  obtained 


For  further  explanation,  see  DOA  Pamphlet  No.  18-8,  "A  Software-Resource 
Macroestimating  Procedure." 

+See  Table  6-02. 
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from  eager  vendors,  a rapidly  changing  state  of  the  art  and,  hence, 
constantly  changing  marketing  schemes  cause  the  validity  of  such 
information  to  be  short-lived.  This  condition  can  be  particularly 
deleterious  when  estimating  hardware  costs  for  long-range  planning. 
Long-range  estimation  must,  therefore,  involve  trend  prediction. 

The  most  difficult  step  in  determining  hardware  costs,  whether 
they  be  for  leasing  or  purchase,  is  the  prerequisite  task  of  determining 
which  configuration  will  best  do  the  job.  It  is  then  a matter  of  con- 
tacting system  vendors  with  these  requirements  and  choosing  among 
alternatives.  Tradeoffs  will  be  involved,  and  the  person(s)  authorized 
to  make  the  actual  decision  must  have  predetermined  ranges  of  system 
specifications  which  they  consider  acceptable. 


Specific  items  to  be  costed  are: 

a.  CPU  (with  X amount  of  memory) 

b.  Mass  storage  (with  Y amount  of  memory) 

c.  Type  and  number  of  I/O  devices 

d.  Other  peripherals  (e.g.,  COM,  plotter) 

e.  Communications  gear 

f.  Removable  data  medium. 


6.4. 1.1  Other  Acquisition  Costs.  When  hardware  or  software  packages 
are  procured,  the  contracted  amount  represents  only  a portion  of  the 
acquisition  costs.  The  cost  of  U SMC /government  personnel  tasked  to 
conduct  source  selection  and  contract  negotiations  is  a marginal  cost 
and  properly  charged  to  the  ADS.  These  costs  are  strongly  dependent 
on  the  particular  circumstances  of  the  development.  Often  they  can  be 
estimated  by  budgeting  a certain  number  of  man-days  or  months  for  the 
process  and  estimating  the  cost  of  these  man-days.  A general  estimating 
relationship  of  5%  of  the  contracted  price  is  not  a reliable  estimator, 
but  may  serve  as  a benchmark  if  the  man-day  estimate  is  not  possible. 

Delivery  costs  attending  hardware  acquisition  must  also  be  esti- 
mated. These  are  noted  generally  as  shipping,  delivery,  checkout,  and 
inspection  charges,  but  may  Include  other  costs  of  bringing  the  hardware 
to  the  point  of  installation.  Since  the  contracted  price  for  larger 
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acquisitions  often  includes  delivery  and  installation,  they  may  be 
buried  in  the  vendor  quotation.  Whatever  the  case,  the  user  should 
check  to  see  that  his  estimate  provides  for  delivery  and  associated 
costs. 

6.4.2  Initial  Training.  This  cost  element  is  estimated  by  forecasting 
the  training  requirement  (i.e.,  in  the  number  of  trained  operators  and 
maintenance  personnel  needed),  and  the  time  required  to  qualify  opera- 
tors. Costs  include  both  the  "billet  costs"  of  the  instructor  and 
student,  travel  and  per  diem,  special  training  equipment  and  facilities, 
and  computer  processing  costs.  Additionally  contracted  services  may 

be  involved  if  the  training  is  to  be  performed  by  a vendor. 

6.4.3  User  Manuals  and  System  Documentation.  System  documentation  is 
part  of  the  ADS  development  cost.  The  cost  element  addressed  here  is 
intended  to  cover  those  costs  incurred  for  drafting  and  printing  the 
system  operation  and  user  manuals,  provided  that  such  materials  are  not 
supplied  by  the  vendor.  Although  subject  to  wide-ranging  variability, 

a convenient  starting  place  for  estimating  these  costs  is  to  equate  them 
to  the  development  documentation  task.  Hence  the  relationship: 

User  Training  Manuals*  Costs  = (.05)  (ADS  Development  Costs) 

6.4.4  Site  Activation.  These  costs  generally  apply  only  to  the  large 
ADS  development  projects.  Covered  in  the  cost  element  are  the  costs  of 
preparing  a facility  to  receive  and  operate  some  form  of  ADS  equipment. 
Specifically,  the  following  items  need  to  be  estimated: 

a.  Facility  planning,  modification,  and  moving  expenses 

b.  Assembly,  installation,  and  checkout 

c.  Initial  rents,  utilities,  and  communications  charges 

d.  Furnishings. 


* 

User-oriented;  not  DoD  specifications;  assumes  that  A&D  and  T&E  phases 
are  well-documented,  if  that  is  not  the  case  this  factor  should  be 
increased  up  to  as  much  as  20Z,  depending  on  the  specific  situation. 


88 


Because  each  application  is  unique  to  its  specific  situation,  the  analyst 
must  base  his  estimates  on  input  from  vendors  and  plant  or  facility 
engineers. 

6.4.5  Initial  Provisioning.  Although  this  category  is  common  for  most 
military  equipment,  its  application  to  ADS  is  often  not  appropriate. 
Equipment  maintenance  is  generally  provided  under  some  form  of  a service 
agreement,  thereby  obviating  the  need  for  spares  and  spare  parts. 
Occasionally  ADS  equipment  is  situated  such  that  USMC  personnel  have 
specific  maintenance  responsibilities,  in  which  case  an  estimate  of 
initial  spares  provisioning  would  be  required. 

Supplies,  materials,  and  certain  special-purpose  maintenance  equip- 
ment are  commonly  required  to  support  an  ADS.  These  items  do  not  usually 
represent  a major  cost.  Estimates  for  the  maintenance  equipment  can 
usually  be  provided  by  the  vendor.  Supplies  are  generally  based  on  a 
resupply  period  plus  a backup  for  emergency  use. 

6.4.6  ADS  Project  Management.  This  cost  element  extends  over  the  entire 
ADS  life  cycle,  typically  running  approximately  10%  of  the  Life  Cycle 
Costs.  The  cost  element  is  treated  as  an  implementation  cost  because  it 
generally  reaches  a peak  activity  level  during  this  phase.  As  with  ADS 
development,  the  analyst  may  select  either  a macro  or  micro  approach 

for  estimating  this  cost.  The  macro  estimate  is  the  above-mentioned 
10%  factor  of  development  and  other  implementation  costs.  For  smaller 
projects,  the  management  staff  can  usually  be  identified,  and  man-day 
(month)  time  for  this  function  can  be  costed  accordingly.  It  is  often 
accounted  as  overhead. 

6.5  Estimating  ADS  Operation  and  Support  (O&S)  Costs.  The  basis  for 
estimating  ADS  (US  costs  is  the  system  conceptual  plan  or  scheme.  Unlike 
ADS  development  costs  where  lack  of  design  detail  is  a serious  problem 
for  the  analyst,  the  conceptual  plan  specifies  the  requirement  for  opera- 
tors, equipment  (or  processing  time),  and  facilities.  Since  these 
requirements  are  typically  part  of  the  design  specifications,  changes 
in  the  system  plan  are  more  or  less  bounded  within  tolerable  limits. 
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Given  these  specifications,  a microestimating  methodology  is  generally 
possible  for  O&S  costs. 

Operating  and  Support  activities  fall  into  one  of  two  groups,  both 
of  which  must  be  estimated.  The  first  is  that  associated  with  the  planned 
system  operation;  system  operators,  keypunch,  computer  processing,  and 
maintenance  cost  and  supplies.  The  second  concerns  the  system  software 
maintenance  and  modification.  A discussion  of  each  category  follows. 

6.5.1  Breakdown  of  System  (O&S)  Costs.  This  category  includes  the  cost 
of  all  operating  personnel,  exclusive  of  those  programmer-analysts  who 
are  assigned  to  maintain  the  currency  of  the  system  software.  It  also 
includes  all  processing  costs,  equipment  leaseholds,  and  hardware  main- 
tenance, as  well  as  all  facility  maintenance,  utilities,  communications, 
and  contract  services. 

There  are  several  difficult  divisions  of  costs,  which  must  be  con- 
sistent and  unbiased.  More  specifically,  personnel  assigned  to  the 
functional  area  may  be  required  to  provide  input  data  to  the  ADS. 

Although  they  may  devote  all  of  their  time  to  this  function,  this  time 
may  not  be  part  of  the  system  cost.  The  criterion  for  determining  ADS 
associated  and  unassociated  cost  is  whether  or  not  the  ADS  requirement 
is  added  to  the  existing  job  duties  had  there  been  no  ADS.  Another  test 
would  be  to  draw  an  analogy  with  an  item  of  unit  equipment,  e.g.,  a 
truck.  In  the  truck  example,  a warehouseman  may  be  assigned  to  load 
and  unload  the  truck  all  of  the  time,  but  he  is  obviously  not  part  of 
the  LCC  of  the  truck.  The  truck  is  a tool  to  perform  a function,  and 
similarly,  so  is  an  ADS. 

The  issue  is  less  a problem  of  correct  allocation  of  cost  than  it 
is  of  unbiased  treatment  of  costs  among  alternative  approaches,  ADS 
or  otherwise.  Particular  care  must  be  exercised  when  comparing  the 
LCC  of  the  manual  and  automated  systems. 

6. 5. 1.1  System  Operations.  Table  6-02  listed  the  LCC  elements  treated 
under  ADS  System  Operations  as  the  following: 

a.  Operator  Personnel  Costs.  To  determine  all  normal  personnel 
costs,  the  recommended  approach  is  to  use  the  "billet  costs"  . 
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shown  in  Appendix  B.  These  costs  account  for  the  many  hidden, 
but  real  costs  of  maintaining  a requirement  for  staff.  It 
will  be  necessary  to  forecast  the  number  and  rank  of  opera- 
tors, data  processors,  and  programmer  analysts  before  the 
proper  costs  can  be  determined. 

b.  Computer  Processing  Costs.  Unless  the  computational  equipment 
is  completely  dedicated  to  the  ADS,  these  costs  are  based  on 
estimates  of  computer  processing  times  and  the  cost  per  unit 
time  as  fixed  by  the  host  activity  or  as  quoted  by  a vendor 

of  the  service.  The  pricing  algorithm  used  should  include 
all  peripheral,  keypunch,  and  associated  charges. 

c.  Supplies  and  Services.  These  costs  are  generally  self- 
explanatory.  They  cover  the  cost  of  paper,  tapes,  cards, 
special  forms,  and  other  such  materials  as  are  required  to 
operate  the  ADS. 

d.  Replacement  and  Training  Operators.  The  "billet  cost"  used 
to  estimate  the  personnel  cost  of  the  operator  covers  the 
normal  replacement  training  for  the  rating  specified.  This 
cost  element  is  intended  to  cover  special  training  required 
to  support  the  ADS.  For  example,  new  operators  may  be  sent 
TDY  to  alternate  locations  for  on-the-job  training  prior  to 
assuming  their  new  duties.  In  such  a case  the  replacement 
training  would  include  the  following: 

(1)  Additional  "billet  cost"  for  training  period 

(2)  Travel  and  per  diem 

(3)  Instructor  and  processing  costs 

(4)  Supplies  and  materials  consumed. 

6. 5. 1.2  Equipment  and  Facility  Maintenance.  The  categories  listed 
are: 


b. 


Maintenance  Personnel  Cost.  These  are  "billet  costs" 
for  those  personnel  assigned  to  equipment  maintenance 
functions . 

Computer  Hardware  Maintenance.  This  cost  may  be  incurred 
as  a service  contract  or  as  maintenance  material  and 
replacement  parts,  or  both.  Some  form  of  maintenance 
agreement  is  typical  for  the  large  central  processing 
activities  (i.e.,  CDPA) . User-level  maintenance  may 
be  part  of  the  remote  terminal  or  minicomputer  equip- 
ment, particularly  those  that  need  to  be  deployable. 
Whatever  the  case,  the  vendor-supplied  maintenance 
cost  estimate  is  a valuable  source  for  determining 
this  cost,  whether  contracted  separately  or  performed 
Internally. 


Utilities,  Rents,  and  Communications.  This  element 
covers  the  general  facility  costs  that  are  incurred 
as  a result  of  the  ADS  operation.  Generally  speaking 
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ADP  systems  are  operated  out  of  government  owned  facil- 
ities where  costs  are  not  separable.  For  this  condition 
a general  rent  figure  may  be  applied  if  the  ADS  space 
requirement  displaces  other  government  uses  for  the 
facility.*  For  ADS  that  require  special  facilities  or 
communication  systems,  all  costs  of  these  special  facil- 
ities are  charged  to  the  ADS.  Care  must  be  taken  to 
avoid  double  accounting.  The  pricing  of  computational 
services  usually  covers  equipment,  facility,  and  main- 
tenance costs.  This  element  is  intended  to  cover  only 
those  costs  that  are  incrementally  added  to  the  unit 
or  host  activity  as  a result  of  operating  the  subject 
ADS. 

d.  Facility  Maintenance  Costs.  The  points  discussed  in 

the  previous  paragraph  apply  here  as  well.  The  facil- 
ity maintenance  of  the  personnel  work  station  is 
included  in  the  "billet  cost"  factor  and  should  not  be 
added  again  unless  the  requirement  causes  additional 
facilities  over  and  above  a normal  working  situation 
(e.g.,  if  a field  office  were  to  be  set  up  to  conduct 
some  function,  the  cost  of  operating  and  maintaining 
it  would  be  considered  "incremental").  A similar 
situation  exists  for  facilities  set  up  to  house  ADS 
equipment,  i.e.,  it  is  not  incremental  to  add  a 
terminal  to  an  existing  work  station,  but  it  would  be 
incremental  to  maintain  rent  space  in  a field  office 
to  house  that  same  equipment. 

6.5.2  System  Software  Maintenance  and  Modification  Costs.  This  category 
of  cost  is  often  the  most  speculative  of  the  ADS  resource  estimates. 
Certain  classes  of  ADS  (e.g.,  fiscal,  manpower,  or  logistics)  require 
considerably  more  modification  than  others.  There  is  also  a noticeable 
difference  in  size  and  type  of  modifications  between  ADS  classes.  More 
than  any  other,  these  costs  are  "managed"  costs,  meaning  that,  to  a 
considerable  extent,  they  are  incurred  at  management's  discretion. 

To  attempt  a parametric  estimating  procedure  would  be  ill-advised.  The 
most  reliable  approach  would  be  to  relate  historical  data  on  ADS  main- 
tenance and  modification  to  the  initial  ADS  development  cost,  categorized 
by  ADS  type  and  supporting  installation. 


A typical  rent  of  $3-5/sq.  ft.  would  be  adequate  to  cover  facility 
costs  that  cannot  be  separably  identified. 
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6. 5. 2.1  Mac roe stima ting  Approach  to  Estimating  Software  Maintenance. 

The  macroestimating  methodologies  presented  in  Section  4 of  the  Resource 
Requirements  Estimating  Technical  Note  for  ADS  development  costs  showed 
the  relationship  of  life  cycle  manning  as  a Rayleigh  distribution  for 
time  as  a dependent  variable.  It  was  also  noted  that,  at  the  end  of 
development,  maintenance  and  modification  activities  begin  when  the 
system  manning  during  development  falls  to  roughly  22%  of  the  maximum 
project  manning.* 

This  manning  l<_vel  offers  a starting  point  in  a procedure  for  esti- 
mating the  ADS  project  staff  of  analyst-programmers  assigned  to  main- 
tenance and  modification  duties.  The  next  step  is  to  reconstruct  ADS 
development  historical  data  to  determine  the  sice-peculiar  management 
response  to  ADS  maintenance  and  modification  requirements.  Finally, 
a ratio  of  maintenance  to  development  staff  should  be  determined  for 
each  functional  area  (i.e.,  class  of  ADS)  and  CDPA.  Such  a ratio  will 
become  a primary  determinant  of  the  cost  of  this  LCC  element. 

6.6  Time  Related  LCC  Estimating.  The  life  cycle  of  an  ADS  is  often  con- 
sidered to  be  development  plus  eight  years  of  operation.  However,  there 
are  no  DoD  instructions  specifying  an  exact  figure  to  be  used  for  life 
cycle  costing,  and  rightly  so.  This  factor  is  a variable  that  differs 
from  system  to  system  and,  hence,  must  be  appraised  on  a case-by-case 
basis.  Costs  for  an  ADS  are  incurred  over  the  entire  life  cycle.  A 
decision  to  develop  an  ADS,  therefore,  commits  the  USMC  to  a flow  of 
funds  over  time,  which  can  be  discounted.  Since  funds  are  spent  in 
future  years,  allowance  must  be  made  for  inflation  as  well.  The  ration- 
ale and  method  of  application  of  discounting  and  inflating  funding  flows 
are  discussed  in  the  following  paragraphs. 

6.6.1  Discounting.  Present  DoD  policy  specifies  that  discounted  cash 
flow  be  used  whenever  the  system  being  considered  requires  funding  for 
a period  of  more  than  three  years.  This  policy  is  stated  again  in 


There  is,  of  course,  considerable  overlap  of  development  and  program 
maintenance.  The  line  between  continued  development  and  system  modifi- 
cation is  not  clear.  This  cutoff  point  is  arbitrary  but  not  unreasonable. 
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Chapter  14  of  che  ADSM.  The  rationale  for  discounting  future  expenditures 
is  that  to  postpone  the  payment  of  any  funds  permits  current  funds  to  be 
invested  to  yield,  presumably,  some  return  (i.e. , benefits).  Another 
way  of  viewing  it  is  to  assume  all  the  funds  are  made  available  at  the 
start  of  a project,  and  those  held  in  reserve  for  future  expenditures 
draw  interest  at  10%  per  annum.  The  point  being  made  is  the  same, 
since  alternatives  being  evaluated  have  different  cash  flows.  These 
flows  must  relate  to  a present  value  for  some  specified  rate  of  return 
so  that  the  alternative  cost  flows  can  be  evaluated  equitably.  DoD 
instruction  7041.3  specifies  an  annual  discount  rate  of  10%.  Table  B-07, 
Appendix  B,  lists  10%  discount  factors  to  use  for  expenditures  beyond 
the  base  year. 

6.6.2  Inflation.  The  treatment  of  inflation  and/or  cost  escalation  for 
expenditures  has  become  a common  part  of  cost  and  economic  analyses. 

DoD  policy  states  that  all  LCC  analyses  reflect  the  total  expected 
cost  to  the  government  for  acquiring  the  system  in  both  constant,  current 
year,  and  inflated  dollars.  Inflation  rates  are  regularly  forecast 
by  cognizant  government  agencies.  The  rates  can  be  guides  to  estimating 
the  effects  of  inflation  as  it  relates  to  alternative  approaches. 

Inflated  costs  should  be  used  in  economic  analyses  whenever  costs  are 
part  of  the  decision  process. 

DoD  instruction  7041.3  calls  for  presenting  LCC  estimates  in  both 
constant  dollars  and  inflated  (then  year)  dollars.  The  instruction 
further  cautions: 

a.  That,  to  avoid  double  accounting,  one  should  investigate  the 
applicability  of  contract  escalation  provisions  or  the  impact 
of  ongoing  fixed  price  contracts  for  goods  and  services 

b.  Estimates  of  inflation  are  very  uncertain  for  longer  periods 
(beyond  four  years),  and  particular  care  should  be  taken. 

A good  procedure  to  follow  would  be  to  investigate  the  effect  of 
using  different  inflation  rates  on  the  decision  reached.  Table  B-08, 
Appendix  B shows  predicted  price  level  indices  recommended  for  use  in 
DoD  studies. 
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6.6.3  Sunk  Costs  and  Residual  Value.  Sunk  costs  are  those  resources 
that  have  been  incurred  or  irrevocably  committed  before  a decision  on 
alternatives  is  to  be  made.  The  correct  treatment  of  sunk  costs  in 
the  Feasibility  Study  or  Economic  Analysis  is  to  exclude  them  from  the 
project  cost  summary.  If  there  is  to  be  a salvage  value  to  the  sunk 
cost  items,  the  net  return  to  the  government  may  be  legitimately  sub- 
tracted from  the  cost  of  the  competing  alternatives  in  the  form  of 
cash  resulting  from  a supposed  sale  or  in  some  other  less  tangible 
form,  e.g.,  initial  training,  facility  modification,  etc. 

At  the  end  of  the  system’s  life,  there  may  be  a projected  residual 
value,  either  in  the  form  of  cash  resulting  from  a supposed  sale  or  some 
other  less  tangible  (but  transferable)  asset  such  as  special  training. 

If  the  asset  can  be  redistributed  to  some  other  government  activity, 
valid  benefits  accrue,  and  they  should  be  credited  to  the  affected 
system  at  fair  market  value. 

Note,  however,  that  since  the  residual  value  occurs  at  the  end  of 
the  system  life,  and  since  the  residual  value  must  be  net  of  removal, 
checkout,  and  disposal  costs,  the  resulting  benefit  may  be  so  small  as 
to  be  ignored  in  the  analysis. 
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APPENDIX  A 


ILLUSTRATIVE  EXAMPLE  OF 
OBJECTIVE-WRITING  METHODOLOGY 


A1.0  This  section  is  devoted  to  an  example  that  illustrates  the  Concept 
Phase  Objective-Writing  Methodology  defined  in  Section  5. 

The  example  is  intended  to  be  generally  realistic  and  to  provide  a 
reasonable  exercise  of  the  features  of  the  objective-writing  methodology. 
Understandably,  any  example  chosen  to  illustrate  the  basic  ideas  within 
the  scope  of  a few  pages  must  be  somewhat  simple  compared  with  many 
actual  cases  encountered  in  USMC  ADS  development. 

Al.l  The  User  Need.  The  user  need  that  is  envisioned  in  this  example 
is  for  an  improved  administrative  and  management  tool  for  garrison-based 
staff  and  action  officers  to  use  in  the  conduct  of  their  daily  work.  It 
is  intended  to  address  the  writing,  composition,  and  document  production 
and  control  required  in  their  work,  together  with  certain  closely  asso- 
ciated activities.  It  is  intended  to  increase  productivity  and  improve 
the  comprehensiveness  and  quality  of  the  work  in  comparison  to  the 
conventional  manual  clerical  modes  of  handling  such  tasks. 

The  intent  is  not  to  impose  on  the  user  a large  encompassing  system, 
but  rather  to  give  him  an  aid  that  appears  to  him  as  his  own  personal 
dedicated  tool  for  performing  and  managing  his  work.  He  should  be  able 
to  regard  it  in  much  the  same  way  as  he  regards  his  own  assigned  type- 
writer or  dictating  machine.  While  it  may  eventually  alter  his  style  of 
working  significantly,  it  should  not  force  him  to  abandon  any  customary 
activities  he  prefers  to  continue,  nor  to  learn  any  new  formal  languages, 
write  computer  programs,  or  engage  in  other  activities  outside  the  scope 
and  interests  of  his  assigned  work.  It  also  should  not  degrade  his 
ability  to  accomplish  any  aspect  of  his  job — for  example,  to  maintain 
the  privacy  of  sensitive  records. 

A2.0  The  Inputs  to  the  Objective-Writing  Example.  In  general,  inputs 
to  objective-writing  consist  of  a body  of  stated  user  requirements, 
applicable  guidelines  and  constraints,  and — if  a Feasibility  Study  has 
previously  been  performed — certain  results  from  the  Feasibility  Study. 

For  the  case  of  this  example,  the  inputs  are  described  below. 

A2.1  User  Requirements.  The  user  requirements  for  the  example  are  the 
following: 
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a.  (Rl)  The  solution  must  provide  an  accessible,  responsive,  easily 
usable  personal  tool  for  a staff  or  action  officer. 

b.  (R2)  The  solution  must  provide  capabilities  for  creating,  manip- 
ulating, and  producing  administrative  information  and  documents 
encountered  in  the  user's  work. 

c.  (R3)  It  must  provide  calculating  capabilities  of  a typical  desk 
calculator  with  some  extended  features. 

d.  (R4)  The  solution  must  improve  upon  conventional  manual/clerical 
methods. 

e.  (R5)  It  must  be  highly  available  and  fully  operational  in  the 
normal  garrison  environment. 

f.  (R6)  It  must  be  easily  maintainable. 

g.  (R7)  It  must  be  economical. 

h.  (R8)  The  solution  must  provide  capabilities  at  least  as  effective 
as  the  current  manual  capabilities  for  protecting  the  security  of 
recorded  material. 

i.  (R9)  It  must  provide  capabilities  for  protecting  the  privacy  of 
recorded  material. 

A2.2  Guidelines  and  Constraints.  For  the  example,  the  following  guide- 
lines and  constraints  apply: 

a.  (GC1)  No  additional  nonvoice  usage  will  be  imposed  on  the  in-house 
telephone  system  by  any  newly  developed  administrative  information 
system  or  aid. 

b.  (GC2)  Any  computer  software  to  be  programmed  or  maintained  in-house 
will  be  written  in  one  of  the  approved  higher-level  languages 
listed  in  Document  XX.  Software  to  be  furnished  and  maintained 
exclusively  by  a vendor/contractor  is  not  subject  to  this 
restriction. 

c.  (GC3)  All  new  in-house  automated  equipment  and  systems  must  be 
strictly  justifiable  on  the  basis  of  tangible,  demonstrable  cost 
savings  (i.e.,  no  intangible  cost  savings  or  intangible  improve- 
ments in  work  quality  will  be  considered) . 

A2.3  Results  of  Feasibility  Study.  For  the  example  assume  that  a 
Feasibility  Study  has  been  conducted,  and  that  the  following  results 
have  implications  for  requirements: 

a.  (FS1)  The  system  to  be  developed  will  be  a self-contained  stand- 
alone system  rather  than  a clustered,  netted,  or  remote  access 
system. 

b.  (FS2)  No  computer  programming  of  the  system  by  users  will  be 
necessary  or  possible. 

A2.4  Restatement  of  the  Inputs.  At  this  point,  the  inputs  are  restated 


for  uniformity  and  convenience.  Since  restatement  is  open  to  individual 
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interpretation,  the  results  can  vary  from  person  to  person.  The  results 
of  the  restatement  for  this  example  are  tabulated  in  Figure  A-01.  Through 
its  identifying  number,  each  item  listed  in  the  figure  can  be  traced  back 
to  an  antecedent  user  requirement,  guidelines  and  constraint,  or  Feasi- 
bility Study  result.  Thus,  for  example,  one  can  see  that  Rl-1.  Rl-2, 

Rl-3,  and  Rl-4  all  relate  back  to  user  requirement  Rl;  or,  conversely, 
that  user  requirement  Rl  has  been  split  into  the  four  statements  Rl-1, 
Rl-2,  Rl-3,  and  Rl-4.  Similarly,  guideline  and  constraint  GC1  has 
been  restated  in  simple  and  direct  requirement  form  as  GC1-1.  Certain 
inputs  (e.g.,  R3  and  GC2)  carry  over  directly  without  restatement. 
Occasionally,  more  than  one  input  will  be  subsumed  under  one  restated 
requirement — as  in  the  case  of  R7  and  GC3  being  combined  into  GC3-1. 

The  complete  tabulation  of  restated  requirements  (Figure  A-01) 
becomes  the  list  of  requirements  used  in  the  operational  procedures  for 
the  objective-writing  example.  The  brief  parenthesized  word  or  phrase 
associated  with  each  requirement  will  be  used  in  the  subsequent  procedures 
as  an  abbreviation  for  the  requirement. 

A2.5  Initial  Trial  Objective  Statements.  An  initial  trial  set  of 
objective  statements  for  the  example  is  tabulated  in  A-02.  The  set  was 
produced  by  inspecting  the  restated  requirements  and  attempting  to  state 
a list  of  technologically  attainable  and  attractive  ADS  objectives  that 
together  address  all  of  the  requirements.  While  basically  sound,  the 
set  contains  some  defects  that  were  overlooked  initially,  and  that  were 
subsequently  revealed  by  application  of  the  various  objective-writing 
procedures . 

A-2.6  Application  of  the  Objective-Writing  Procedures.  For  the  illus- 
trative example,  each  of  the  objective-writing  procedures  is  illustrated 
using  the  trial  set  of  objective  statements  exhibited  in  Figure  A-02. 

In  an  actual  system  development  case,  the  trial  set  would  be  modified 
after  the  application  of  each  procedure  to  reflect  the  improvements 
induced  by  that  procedure.  The  improved  set  would  then  be  submitted  to 
the  next  procedure.  For  purposes  of  illustration,  only  a small  number 
of  results  typical  of  each  procedure  are  noted.  The  reader  who  pursues 
the  procedures  further  will  discover  other  results  and  conclusions. 
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Rl-1  (Personal  cool)  The  solution  must  be  a personal  tool  for  Che  staff 

or  accion  officer. 

Rl-2  (Accessibility)  The  solution  must  be  accessible  to  the  user. 

Rl-3  (Responsiveness)  It  must  be  responsive  to  the  user. 

Rl-4  (Utility)  It  must  be  usable  to  the  user. 

R2-1  (Creation  capabilities)  It  must  provide  creation  capabilities  for 

user's  information  and  documents. 

R2-2  (Manipulation  capabilities)  It  must  provide  manipulation  capabili- 

ties for  user's  information  and  documents. 

R2-3  (Production  capabilities)  It  must  provide  production  capabilities 

for  user's  information  and  documents. 

R3  (Calculating  capabilities)  It  must  provide  the  calculating  capabili- 

ties of  a typical  desk  calculator  with  some  extended  features. 

R4  (Improved  methods)  It  must  improve  upon  conventional  manual/clerical 

methods. 

R5-1  (Availability)  It  must  be  highly  available  in  the  normal  garrison 

environment. 

R5-2  (Operation)  It  must  be  fully  operational  in  the  normal  garrison  en- 

vironment. 

R6  (Maintainability)  It  must  be  easily  maintainable. 

R8  (Security)  The  solution  must  provide  capabilities  at  least  as  effec- 

tive as  the  current  manual  capabilities  for  protecting  the  security 
of  recorded  material. 

R9  (Privacy)  The  solution  must  provide  capabilities  for  protecting  the 

privacy  of  recorded  material. 

GC1-1  (Telephone  usage)  The  solution  will  not  connect  to  the  in-house 

telephone  network. 

GC2  (Programming  language)  Any  computer  software  to  be  either  programmed 

or  maintained  in-house  will  be  written  in  one  of  the  approved 
higher-level  languages  listed  in  Document  XX.  Software  to  be  fur- 
nished and  maintained  exclusively  by  a vendor/contractor  is  not  sub- 
ject to  this  restriction. 
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(Cost  justification)  The  solution  must  result  in  demonstrable  equip- 
ment savings,  supply  savings,  clerical  labor  savings,  and  user  labor 
savings  that  will  offset  its  cost. 


FS1  (Stand-alone  system)  The  solution  will  take  the  form  of  a self- 

contained  stand-alone  system. 

FS2  (User  programming)  No  computer  programming  of  the  system  will  be 

necessary  or  possible. 


■ 
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OBI  (Text  editing)  The  system  shall  provide  the  following  text  editing 

functions : 

- inserting  strings  of  text  (one  or  more  characters)  into  existing 
text 

- deleting  strings  of  text  from  existing  text 

- copying  existing  text  to  a new  location 

- moving  existing  text  to  a new  location 

- locating  occurrences  of  text  strings  in  existing  text  for  iden- 
tification or  modification. 

0B2  (Text  formatting)  The  system  shall  provide  the  following  text  for- 

matting functions  for  displayed  and  output  text; 

- variable  control  of  page  length 

- variable  control  of  line  length 

- variable  control  of  line  spacing 

0B3  (Arithmetic)  The  system  shall  perform  the  following  arithmetic 

functions; 

i 

! 

- addition,  subtraction,  multiplication,  division 

i 

- repeated  multiplication  with  accumulation 

I 

i - square  root 

i 

- exponentiation 

I 

- computation  of  logarithms 

0B4  (Data  entry)  The  system  shall  provide  on-line  keyboard  data  entry 

capabilities  for  textual  narrative,  tabular  information,  and  al- 
phanumeric data. 

; 0B5  (Storage  and  retrieval)  The  system  shall  be  capable  of  referencing, 

storing,  retrieving,  and  manipulating  as  single  files  Information  in 
amounts  up  to  400,000  characters. 
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0B6  (Template  manipulation)  The  system  shall  have  the  capability  to  in- 

put, store,  retrieve,  and  fill  out  templates  for  administrative 
forms  and  documents. 

0B7  (Calendar/clock)  The  system  shall  provide  a calendar  and  clock  for 

scheduling,  prompting,  and  time  stamping  of  chronological  events. 

0B8  (File  utilities)  The  system  shall  provide  the  following  file  utili- 

ty functions: 

- copying  files 

- deleting  files 

- printing  files 

- compiling  a directory  of  files 

0B9  (Removable  storage)  The  system  shall  be  capable  of  storing  files 

on,  and  retrieving  files  from,  a removable  storage  medium. 

0B10  (Interoperability)  The  removable  output  media  of  the  system  shall 

be  readable  by  other  similar  systems  and  by  standard  computer-based 
systems. 

0B11  (File  limit)  The  maximum  size  of  files  accommodated  by  the  system 

shall  be  400,000  characters. 

0B12  (Hardcopy  output)  The  system  shall  be  capable  of  outputting  hard- 

copy at  a rate  of  30  characters  per  second. 

0B13  (Calculating  speed)  Response  times  for  arithmetic  calculations 

shall  be  at  least  as  good  as  those  of  a typical  pocket  calculator. 

0B14  (Up-time)  The  system  shall  be  operable  each  month  an  average  of  98Z 

of  the  time  for  two  work  shifts  per  day. 

0B15  (Physical  security)  The  system  shall  be  physically  closable  and 

lockable  with  a degree  of  security  equivalent  to  that  of  a SECRET 
document  container. 

0B16  (Password  protection)  The  system  shall  provide  for  file  protection 

permitting  unique  passwords  for  each  file. 

0B 17  (Packaging  and  size)  The  system  shall  be  completely  contained  in 

either  one  or  two  cabinets  whose  total  cube  shall  not  exceed  that  of 

a standard  office  desk. 
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(Air  conditioning)  The  system  shall  operate  without  external  air 
conditioning  or  humidity  control. 

(Power  sources)  The  system  shall  operate  on  standard  110  volt,  60 
Hz,  15  amp  (max)  power. 

(Physical  modularity)  The  system  shall  be  modularly  constructed  and 
interconnected  such  that  all  major  devices  and  components  of  those 
devices  can  be  replaced  as  modules. 

(Typewriter  equivalence)  The  system  shall  be  capable  of  being  used 
as  the  strict  equivalent  of  a standard  office  typewriter. 

(Stand-alone  capability)  The  system  shall  operate  as  a completely 
self-contained  stand-alone  functional  unit. 

(User  interface)  The  system  shall  be  suited  for  use  by  anyone  who 
can  operate  an  electric  typewriter  or  portable  electronic  calcula- 
tor. 

0B24  (Functional  completeness)  The  system  shall  come  to  the  user  with  a 

complete  repertoire  of  functions  and  not  require  any  programming  by 
the  user. 

0B25  (Diagnostics)  The  system  shall  include  intrinsic  error  detection 

and  diagnostic  capabilities  for  each  major  component  device. 

0B26  (Output  quality)  Hardcopy  output  of  the  system  shall  be  of  suffi- 

cient quality  to  reproduce  well  under  standard  office  copying 
methods. 
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A2.7  Requirements  Mapping.  An  illustrative  mapping  of  the  restated 
requirements  (Figure  A-01)  into  the  trial  objectives  (Figure  A-02)  is 
shown  in  Figure  A-03.  In  the  figure,  any  box  that  has  no  entry  should 
be  interpreted  as  containing  a zero.  The  zeros  have  been  omitted  merely 
to  improve  the  legibility  of  the  matrix.  The  entries  in  the  table  are 
intended  to  be  realistic  and  meaningful  entries  for  this  example  case. 

Some  of  the  entries  are,  nevertheless,  open  to  interpretation  and  would 
merit  discussion  in  a more  extended  treatment  than  can  be  given  here. 

Applying  the  types  of  column-by-column  and  row-by-row  analyses 
called  for  by  the  methodology  reveals  several  inadequacies  or  possible 
improvements  in  the  objective  set.  For  example,  the  column  under  GC2 
(Programming  language)  consists  entirely  of  zeros.  This  reveals  that 
there  is  no  objective  in  the  trial  set  that  addresses  requirement  GC2. 

One  or  perhaps  more  objectives  should  be  added  to  the  trial  set  to 
accommodate  requirement  GC2.  The  columns  under  GC1  (Telephone  usage)  and 
FS2  (User  programming)  each  have  only  one  plus.  Analysis  shows  that  the 
two  objectives  accounting  for  the  pluses  do  not  strongly  guarantee  the 
fulfillment  of  the  two  requirements  in  question.  Additional  reinforcing 
objectives  should  be  added. 

Columns  1,  2,  and  4 are  heavily  filled  with  pluses.  On  investigation, 
the  requirements  represented  by  these  columns  appear  to  be  fully  met  by 
(mapped  into)  the  objectives  of  the  trial  set.  This  is  indicated  by  the 
checkmarks  at  the  bottoms  of  the  columns.  Other  columns  may  fall  into 
this  category  as  well. 

Each  of  the  instances  of  minus  signs  in  the  matrix  should  be  investi- 
gated. For  example,  in  the  row  for  0B16  (Password  protection)  the  minus 
sign  indicates  the  fact  that  password  protection  of  files  interferes 
somewhat  with  accessibility  for  even  the  system's  authorized  user. 
Nevertheless,  the  offsetting  benefits  regarding  security  (R8) , privacy 
(R9) , utility  (Rl-4),  and  improved  methods  (R4)  appear  to  more  than 
compensate  in  this  case. 
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oai  TEXT  EDITING 


OB2  TEXT  FORMATTING 


OB3  ARITHMETIC 


OB4  DATA  ENTRY 


085  STORAGE  ANO  RETRIEVAL 


0B6  TEMPLATE  MANIPULATION 


0B7  CALENDAR/CLOCK 


0B8  FILE  UTILITIES 


0B9  REMOVABLE  STORAGE 


OBIO  INTEROPERABILITY 


OB1 1 FILE  LIMIT 


OB  12  HARDCOPY  OUTPUT 


0B13  CALCULATING  SPEED 


0614  UP-TIME 


OBI 5 PHYSICAL  SECURITY 


0B16  PASSWORD  PROTECTION 


OBI 7 PACKAGING  AND  SIZE 


O BIB  AIR  CONDITIONING 


0B19  POWER  SOURCE 


OB20  PHYSICAL  MODULARITY 


0B21  TYPEWRITER  EQUIVALENCE 


OB 22  STANDALONE  CAPABILITY 


0823  USER  INTERFACE 


OB24  FUNCTIONAL  COMPLETENESS 


0B2S  DIAGNOSTICS 


OB26  OUTPUT  QUALITY 


y/ 


y/ 


FIGURE  A-03  ILLUSTRATIVE  REQUIREMENTS  MAPPING 
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A2.8  Simplicity  Check.  A critical  reading  of  each  objective  with 
respect  to  its  simplicity  reveals  some  opportunities  to  split  composite 
objectives.  For  example,  0B17  (Packaging  and  size)  is  really  a dual 
statement  that  would  be  better  separated  into: 

a.  0B17-1  (Packaging).  The  system  shall  be  contained  in  either 
one  or  two  cabinets. 

b.  OB17-2  (Size).  The  total  cube  of  the  system  shall  not  exceed  that 
of  a standard  office  desk. 

Analyzing  each  of  the  objectives  into  its  functional,  performance, 
physical  design,  and  system  quality,  implications  also  reveals  some 
opportunities  to  produce  simplified  objectives.  For  example,  0B12  (Hard- 
copy output)  has  both  a functional  implication  and  a performance  implica- 
tion. These  can  be  separated  and  written  respectively  as: 

a.  0B12-1  (Hardcopy  output).  The  system  shall  be  capable  of 
printing  hardcopy  output. 

b.  OB12-2  (Printing  rate).  The  system  shall  print  at  least  30 
characters  per  second. 

A2.9  Pairwise  Checks.  Pairwise  checks  for  consistency,  independence, 
and  comparability  have  considerable  potential  for  improving  the  trial 
set.  For  example,  when  0B12  (Output  rate)  is  paired  with  0B13  (Calculat- 
ing speed),  an  ostensible  inconsistency  comes  to  light.  If  the  output 
rate  called  for  by  0B12  is  the  maximum  rate  at  which  the  system  can  display 
(print)  arithmetic  operands  (numbers),  then  the  printing  times  alone  will 
far  exceed  the  response  times  seemingly  called  for  by  0B13.  However,  if 
0B13  is  interpreted  to  mean  that  calculations,  exclusive  of  operand 
printing,  will  be  performed  as  fast  as  those  of  a typical  electronic 
pocket  calculator,  then  the  inconsistency  is  resolved. 

An  example  of  nonindependence  (overlap)  is  revealed  when  0B11  (File 
limit)  and  0B5  (Storage  and  retrieval)  are  paired  and  analyzed  together. 
Both  specify  the  same  maximum  file  size  of  400,000  characters  for  the 
system.  The  set  of  objectives  would  be  improved  and  the  simplicity  of 
0B5  would  be  enhanced  by  eliminating  the  reference  to  file  size  from  0B5. 

A2.10  Determinabllity  Analysis.  Analysis  of  0B10  (Interoperability) 
pinpoints  a determinability  problem.  The  reference  to  "standard  computer- 
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based  systems"  must  be  better  defined  to  make  objective  fulfillment 
determinable.  It  could,  for  example,  be  changed  to:  "Computers  having 
the  appropriate  type  of  input/output  device  and  employing  the  American 
Standard  Code  for  Information  Interchange  (ASCII)." 

Determinability  analysis  of  0B18  (Air  conditioning)  suggests  the 
need  to  restate  the  objective  to  include  specification  of  desired 
environmental  temperature  and  humidity  limits.  It  further  indicates 
the  need  to  provide  for  eventual  operational  tests  of  the  system  under 
appropriate  environmental  extremes  to  determine  whether  it  fulfills  the 
stated  objective. 


APPENDIX  B 


DEFINITION,  DERIVATION,  AND  MODIFICATION  OF 
MICROESTIMATING  WEIGHTING  AND  SCORING  FACTORS 


■ i 


B-l. 0 The  following  definitions  describe  the  microestimating  factors 
in  the  context  of  the  proposed  methodology: 


a.  System  Complexity — This  refers  to  the  combined  level  of  difficulty 
in  programming  the  various  components  of  the  system.  Care  must 

be  taken  not  to  confuse  amount  with  difficulty.  As  an  example, 
three  fixed-length  record  input  files  may  be  easier  to  program 
than  a single  variable-length  record  input  file.  Program  com- 
plexity is  analogous. 

b.  Experience — Analyst  A&D  experience  and  programmer  programming 
experience  refer  to  the  amount  of  general  background  and  use  of 
those  skills  by  the  analyst  and  programmer,  respectively.  In 
many  cases  this  is  directly  proportional  to  military  rank  or  GS 
grade. 

c.  Job  Knowledge — This  refers  to  functional  knowledge  of  the  specific 
application  which  is  to  be  automated,  or  if  currently  automated, 
knowledge  of  the  existing  automated  system  as  well. 

Derivation  of  weighting  scales  for  application  against  the  above 
factors  was  relatively  straightforward.  The  crucial  task  was  to  identify 
all  of  the  parameters  involved  and  their  interrelationships  in  each 
developmental  subphase.  Each  subphase  was  then  further  divided  into  the 
specific  activities  of  which  it  is  comprised.  "Expert  judgment"  is 
sufficiently  accurate  at  this  level  for  estimation  purposes.  Any 
experienced  analyst  who  currently  has  the  authority  to  produce  estimates 
is  qualified  to  use  this  system.  The  use  of  bottom-up  techniques  is 
obvious.  Activity  estimates  are  combined  to  produce  subphase  estimates, 
which  are  in  turn  combined  to  produce  a single  overall  estimate  for  the 
development  phase. 

Several  constraints  had  to  be  observed  when  developing  the  scales 
presented.  First,  the  relative  complexities  of  the  activities  to  each 
other  determined  the  variation  in  ranges.  Second,  it  is  important  for 
the  estimator  to  remember  that,  with  respect  to  programming  effort, 
complexity  is  not  linear.  To  impress  the  importance  of  this  on  the 
estimator,  the  complexity  scales  are  subdivided  into  logarithmic  cate- 
gories (the  terms  "Simple,"  "Average,"  "Complex,"  and  "Very  Complex" 
have  only  conceptual  meaning).  Third,  the  relative  level-of-ef fort 
among  the  subphases — i.e.,  A&D,  programming,  and  T&E — was  determined 
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from  the  literature  to  be  approximately  40,  20,  and  40%  respectively. 
Given  these  constraints,  it  was  a straightforward  procedure  to  derive 
numbers  that  would  produce  estimates  in  the  desired  range  of  two  man- 
weeks  to  six  man-years. 

Modification  of  the  weighting  factors  may  be  necessary  if  the 
methodology  yields  a biased  distribution  estimate.*  The  success  of  using 
the  microestimating  equation  is  dependent  upon  feedback  from  prior  usage. 
In  this  way  actual  versus  estimated  man-hours  may  be  monitored  to  deter- 
mine the  source  of  error.  This  feedback  should  also  be  used  to  improve 
the  analyst's  ability  to  determine  the  appropriate  weighting  factor. 

When  a considerable  amount  of  historical  data  is  collected,  sophis- 
ticated mathematical  techniques — e.g.,  multiple  regression  analysis — 
may  be  employed  to  determine  the  weighting  factors.  A discussion  of  such 
techniques  is  not  within  the  scope  of  the  material  presented  here.  The 
point  to  be  made,  however,  is  that  the  analyst  has  a variety  of  mathe- 
matical tools  at  his  disposal,  which,  with  a sufficient  amount  of 
historical  data,  will  enable  him  to  refine  the  equation  parameters  pro- 
duced in  this  report.  The  refinement  process  is  considered  an  essential 
part  of  this  proposed  methodology. 

B-2.0  Tables  B-01  through  B-03  are  sample  scoring  sheets  for  applying 
the  microestimating  methodology.  Table  B-04  is  a sample  worksheet  for 
microestimating. 

Tables  B-05  and  B-06  show  the  1976-1977  total  cost  per  man-year  of 
military  and  civilian  personnel  as  it  applies  to  Life  Cycle  Cost  studies. 
These  constitute  the  fully  loaded  (marginal)  cost  to  the  government  for 
maintaining  a billet  requirement. 

Tables  B-07  and  B-08  list  two  cost  Indicies  needed  in  conducting 
Life  Cycle  Cost  estimates.  Table  B-07  shows  the  10%  discount  factor 
for  future  expenditures.  Table  B-08  shows  a projected  inflation  index 
for  future  development  and  procurement  expenditures. 

* 

If  the  bias  applies  to  all  components  uniformly,  the  Productivity 
Degradation  Factor  is  the  appropriate  term  to  modify. 
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TABLE  B-01 


ANALYSIS  AND  DESIGN  (A&D)  WEIGHTING  SCALES* 

s 

A&D 

Complexity 

Activity 

Simple 

Average 

Complex 

Very  Complex 

Design  system  flow 

0-3 

4-11 

12-35 

36-100 

Design  input  forms/report 
formats 

0-3 

4-7 

8-20 

21-  50 

Design  master  files 

0-3 

4-12 

13-40 

41-150 

Design  input  files 

0-3 

4-11 

12-35 

36-100 

Design  output  files 

0-3 

4-11 

12-35 

36-100 

Design  intermediate  files 

0-3 

4-11 

12-35 

36-100 

Design  programming  logic 

0-4 

5-15 

16-60 

61-200 

Write  program  specs 

0-3 

4-7 

8-20 

21-50 

Develop  T&E  plan 

0-3 

4-12 

13-40 

41-150 

Develop  training/ 
implementation  plan 

0-3 

4-12 

13-40 

41-150 

Analyst's  Capability 

A&D 

Experience 

Job  Knowledge 

Considerable 

2.0 

2.0 

Average 

1.5 

1.5 

Little 

1.0 

1.0 

None 

0.5 

0.5 

These  scales  also 


apply  to  the  T&E  equation. 
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TABLE  B-02 


PROGRAMMING  WEIGHTING  SCALES 


Activity 


Program  Complexity 


Simple  Average  Complex  Very  Complex 


I/O 

0-1 

2 

3-5 

6-12 

Edit /validation 

0-1 

2 

3-5 

6-12 

Sort /merge* 

0-1 

2 

3-5 

6-12 

Lookup/search 

0-1 

2 

3-4 

5-10 

Calculations 

0-1 

2 

3-5 

6-12 

Update 

0-1 

2 

3-4 

5-10 

Utilities  or  subroutines 

0-1 

2 

3-4 

5-8 

JCL 

0-1 

2 

3-4 

5-8 

Programmer's  Capability 

Programming  Experience 

Job  Knowlei 

Considerable 

2.0 

2.0 

Average 

1.5 

1.5 

Little 

1.0 

1.0 

None 

0.5 

0.5 

Turnaround  Factor 

Value 

Interactive 

.7 

More  than  once  per  day 

1.0 

Once  per  day  or  less 

1.5 

*If  not  done  by  a utility. 


TABLE  B-03 
TEST  AND  EVALUATION 

T&E  Requirement /Component 


Activity 

Low 

Average 

High 

2 

Operational  tests 

0 

1 

Technical  reviews 

0 

1 

2 

Hardware/software  verification  tests 

0 

1 

2 

Data  base  control  tests 

0 

1 

2 

Program/file  security  tests 

0 

1 

2 

I 


TABLE  B-04 

MICROESTIMATING  SAMPLE  FORM 
ESTIMATING  ADS  DEVELOPMENT  TIME 
(Saaple  Worksheet) 


AU)  Complexity 


Activity  Simp 
Design  System  Flow  0*3 
Design  Input  Forms/Report  Formats  0-3 
Design  Master  Files  0-3 
Design  Input  Files  0-3 
Design  Output  Files  0-3 
Design  Intermediate  Fi'les  0-3 
Design  Programming  Logic  0-4 
Write  Program  Specs  0-3 
Develop  TIE  Plan  0-3 
Develop  Trainlng/Implcmentat ion  Plan  0-3 


Simple 

Average 

Complex 

Very  Coa| 

0-3 

4-11 

12-35 

36-100 

0-3 

4-7 

8-20 

21-50 

0-3 

4-12 

13-40 

41-150 

0-3 

4-11 

12-35 

36-100 

0-3 

4-11 

12-35 

36-100 

0-3 

4-11 

12-35 

36-100 

0-4 

5-15 

16-60 

61-200 

0-3 

4-7 

8-20 

21-50 

0-3 

4-12 

13-40 

41-150 

0-3 

4-12 

13-40 

41-150 

ANALYST  EXPERIENCE 


ANALYST  JOB  KNOWLEDGE 


AU)  SUBTOTAL 


SYSTEM  COMPLEXITY 
EXPERIENCE  ♦ JOB  KNOWLEDGE 


AU)  SUBTOTAL 


Prc 

igram  Comp 

lexity 

Activity 

Simple 

Averaf 

[€■  Complex 

Very  Complex 

I/O 

0-1 

2 

3-5 

6-12 

Edit/Val idat ion 

0-1 

2 

3-5 

6-12 

Sort /Merge 

0-1 

2 

3-5 

6-12 

Lookup/Search 

0-1 

2 

3-4 

5-10 

Ca lculat ions 

0-1 

2 

3-5 

6-10 

Update 

0-1 

2 

3-4 

5-10 

Uti lit les/Subrout ines 

0-1 

2 

3-4 

5-8 

JCL 

0-1 

2 

3-4 

5-8 

PROGRAM  1 PROGRAM  2 PROGRAM  3 PROGRAM  4 PROGRAM  5 

SCORE  SCORE  SCORE  SCORE  SCORE 


SCORE  TOTALS  - 
PR  (X,  RAMMER  EXPERIENCE  ♦ JOB  KNOWLEDGE  - 


PROGRAMMING  SUBTOTAL  = ( ^ 


- PROGRAMMER  EXPERIENCE  ♦ JOB  KNOWLEDGE 


PROGRAMMING  SUBTOTAL  » 


Activity 

TliE  Requirement /Component 

Low  Average  High 

Operational  Tests 

0 

1 

2 

Technical  Reviewa 

0 

1 

2 

Hardware/ Soft ware 

Verification  Tests  0 

1 

2 

Data  Base  Control 

Tests  0 

1 

2 

Program/File  Security  Teats  0 

1 

2 

TRE  SUBTOTAL  

SYSTEM  COMPLEXITY 

MTER 

'AVG 

EXPERIENCE  ♦ AVG  JOB  KNOWLEDGE' 

AVERAGE  EXPERIENCE  « 
AVERAGE  JOB  KNOWLEDGE 
TURNAROUND  « 

TU:  SUBTOTAL  « 


Interactive  > Once/Day  < Once /Day 
TURNAROUND  FACTOR  .7  1.0  1.3 

(Circle) 


DOCUMENTATION  PRODUCTIVITY  DEGRADATION 

(1.05)  x (1.6)  - 1.68 


TOTAL  DEVELOP* NT  MAN-DAYS 
< AND  ♦ <PN0GNA<6<1NG  ♦ TNE  ) I TURNAROUND)  > 1 .68 
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TABLE  B-05 

MILITARY  BILLET  COST1  FOR  LCC  STUDIES 


Cost  in  1977  Dollars /Man-year 


Enlisted 


Officers 

E3/01 

E4/02 

E5/03 

E6/04 

E7/05 

E8/06 

E9 

DP* 

17,500 

20,700 

25,100 

31,000 

33,300 

37,500 

43,100 

DS** 

20,100 

22,900 

28,300 

34,400 

36,000 

40,700 

51,000 

Officers 

30,000 

38,400 

44,000 

54,800 

64,200 

86,400 

Cost 

in  1977  1 

Dollars/Man- 

-day^ 

DP* 

80 

94 

114 

141 

151 

170 

196 

DS** 

91 

104 

129 

156 

164 

185 

232 

Officers 

136 

174 

200 

249 

292 

393 

Source:  Navy  Military  Manpower  Billet  Cost  Data  for  Life  Cycle  Planning 
Purposes,  NAVPERS  15163,  July  1973. 

*DP — Data  Processing  Technician  (MOS  4016,  4034) 

**DS— Data  System  Technician  (MOC  4038,  4044,  4063,  4065,  4069) 


1Billet  Cost  includes:  MPA  proficiency  pay,  retirement,  payroll  charges, 
training,  transportation,  reenlistment.  Cost  estimates  are  based  on 
scaling  1973  dollars  to  1977  dollars  according  to  the  ratio  of  MPA  for 
1976/1973. 


2 Based  on  220  man-days  per  man-year. 


TABLE  B-06 


CIVILIAN  PERSONNEL  "BILLET"  COST  FOR  LCC  STUDIES 


Annual  Cost  (1977  Do liars /Man-Year) 


GS-2 

GS-3 

GS-4 

GS-5 

GS-6 

GS-7 

17,200 

19,300 

24,200 

26,800 

29 , 700 

33,000 

GS-8 

GS-9 

GS-11 

GS-12 

GS-13 

GS-14 

36,500 

40,100 

48,200 

57,000 

67,700 

79,700 

Man-Day 

Cost  (1977  Dollars /Man-Day) 

* 

GS-2 

GS-3 

GS-4 

GS-5 

GS-6 

GS-7 

76 

86 

108 

119 

132 

147 

GS-8 

GS-9 

GS-11 

GS-12 

GS-13 

GS-14 

162 

178 

214 

253 

301 

354 

Source:  SRI  International 


I 


* 


Based  on  225  man-days 


per  man-year. 
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TABLE  B-07 


1 


TEN  PERCENT  ANNUAL  DISCOUNT  FACTORS 


Base  Year  + 

1.000 

1 

0.954 

2 

0.867 

3 

0.788 

4 

0.717 

5 

0.651 

6 

0.592 

7 

0.538 

8 

0.489 

9 

0.445 

10 

0.405 

11 

0.368 

12 

0.334 

13 

0.304 

14 

0.276 

15 

0.251 

16 

0.228 

17 

0.208 

18 

0.189 

19 

0.172 

20 

0.156 

Note:  These  factors  are  equivalent 
to  an  arithmetic  average  of 
beginning  and  end  of  the  year 
compound  amount  factors  found 
in  standard  present  value 
tables. 
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TABLE  B-08 


PRICE 

Year 

1977 

1978 

1979 

1980 

1981 

1982 

1983 

1984 

1985 

1986 

1987 

1988 

1989 

1990 


Source 


LEVEL  INDICES 

(BASE  YEAR  1977) 

Development 

Procurement 

1.000 

1.000 

1.058 

1.056 

1.096 

1.100 

1.142 

1.144 

1.184 

1.190 

1.230 

1.237 

1.277 

1.287 

1.324 

1.338 

1.375 

1.392 

1.427 

1.447 

1.481 

1.505 

1.538 

1.566 

1.596 

1.628 

1.657 

1.693 

: ASD  (PA&E)  Memorandum,  13  March 
1975.  Reported  In  Ref.  Bellance, 
USAR  Cost  Effectiveness  Program 
Plan. 
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